Web 2.0 Users/Consumers in the Enterprise
The last 2 years in web startups and general usability improvements online have been fascinating. A product of this innovation period is a consumer/userbase of individuals who come to expect the same experience out of every web-based application they use online and at their day jobs. I love the passion!
There was a good post and subsequent discussion started at this blog asking "Why do enterprise applications suck?"
There is no disputing that most enterprise apps are terrible. Let's examine why:
- Enterprise applications span careers. Very rarely do you get an opportunity to start at ground zero in the enterprise with an application. Web startups have the luxury of starting with a blank sheet of paper. In the enterprise, you're either integrating with legacy systems or building on existing processes that are engrained in the business. Furthermore, long-tenured "champions" are hard to come by as it relates to enterprise applications which brings me to my next point:
- Enterprise applications are inherited. In my case, I've inherited a handful of applications from predecessors who inherited applications from their predecessors. Often times in the enterprise, applications that have been in production have years of usage behind them and are tightly woven into day-to-day business processes. Well, there must be documentation on how the software operates, right? Not quite.
- Enterprise applications are wide in focus. Most web-based startups are narrow in their focus. In the enterprise, one solution rarely fits all needs and business processes, so you're forced to do patchwork between disparate technologies. The startups that try to be "all things to all people" ultimately fail. Look at these lists of startups out of TechStars and you'll find that they're all laser-beam focused. Enterprise application providers are selling "one size fits all" solutions to corporate clients, so don't plan on there being a community of "theme developers" for your enterprise app like there are for WordPress blogs.
- In the early days, the enterprise valued function over form. Looking back as little as 5 years ago, companies were still just discovering web technologies. When going from a manual, paper-based process to your first automated, electronic solution, everyone's going to love it. Fast forward a few years and here we are, usability stewards with high expectations of web application usability. We've been spoiled with free services from the Google, Yahoo!, Facebook, and other online entities.
There's a paradigm shift taking place with the expectations of applications
The evolving nature of web applications is no different than any other maturing industry. Automotive manufacturers experienced the same challenges. Early automobiles valued function: getting you from point A to point B. As that became the standard, automobiles had to differentiate on other features. Early enterprise applications valued function, however in the world of applications, advancements are not measured in decades like automobiles, they are measured in years or even months.
The enterprise will catch up.
Just like most consumers don't rush out and buy the latest car or truck to take advantage of the latest and greatest innovations from the manufacturer, enterprises aren't going to invest in software upgrades that don't promise increased top-line sales or improved bottom line results.
That 1999 model year vehicle still serves its purpose -- insurance is cheap, you have no car payments, and it still runs despite the occasional service it requires. The bells and whistles in new automobiles sure are attractive but they just aren't enough to sway you to make the plunge for a new automobile. The same thinking is taking place in the enterprise with regards to the applications the organization invested in years ago.
A lesson in client servicing an application development project
We recently completed our first integration with an external customer website and our e-commerce website. (By "integration," I mean an API in which we pass configured product data from our site to a 3rd party shopping cart.) What ensued was an interesting learning experience for myself and our group of developers on the project.
Everybody has their own development process
Standards are hard to come by in the web application/development world and the process for managing development projects is certainly no different.
Case in point: We created a technical specification for an API and worked with developers on our own team spanning 3 different time zones. Add on top of this that our technical specification was an "ideal world" document which didn't account for specific requirements of the external website we were to interface with. This meant further coordinating our simultaneous development of our API with the integration of the API (as we were building it). This essentially equated to "building the plane as we flew it."
Agile development is great...but falls flat on its face when involving people outside the core team
In an agile software development world, code is written, tested, and released in several mini-stages. This methodology allows for us to be very open, flexible, and speedy with new development on our various web properties.
However, my takeaway from this project is that I would utilize a different approach when interfacing with external developers that are not part of the core team...taking me back to my agency roots when educating our clients about "our process." What we found is that our process didn't at all align with the customer's process for development, testing/QA, and release management. In fact, it caused a lot of tension between the two groups throughout the project -- especially in the home stretch.
Where we normally operate in a lean environment with small release gaps and short testing periods, the external party we interfaced with was accustomed to a more traditional waterfall model of building the entire application up front, test all of it at once, and going through several iterations of testing & debugging of all code at the very last stage.
Lesson learned: Provide a visual map of your process and timing
Multiple lessons were learned on this project:
1.) Provide a "site map" of the intended integration. This allows business stakeholders to visually understand where the API "handshake" occurs between the sites. It also empowers the external QA team to understand the bigger picture so they can see which areas need testing.
2.) Provide a map of the major components of the development project, timing on each, and the order in which they will be developed. Seems simple, but when you don't manage the external developers, keeping tabs on the timeline proves difficult.
3.) Schedule regular daily meetings to check in on status and even if there's no updates to report, it provides a crutch for the collective team to lean on so everybody remains on the same page (in terms of timing & expectations). Morning meetings are important so the day doesn't get away from either party. This is particularly helpful in the final weeks/days of the project.
Business and IT: A Love/Hate Relationship. But why?
As I've transitioned from the marketing department as a web marketing manager to the IT department as an application/development manager, to my now current role of senior IT manager, I've gradually moved up the food chain of strategy conversations with both the internal business, customers, and vendors. The constant theme in all of these discussions whenever IT is brought up? Resources (or lack thereof) and the roadblock IT is viewed as to growing the business.
Is every IT department eternally busy?
I don't understand it. Well, actually, I do, but I'll say "I don't understand" just to make it sound like I'm in more disbelief than I really am. The underlying theme of every conversation I've had with a customer, vendor, or otherwise is that IT is busy and doesn't have the resources. It seems as if any project requiring IT resources automatically gets held up in the "IT vortex" of priorities. IT departments are really not this busy.
The IT prioritization issue
Something is fundamentally wrong when IT resources are scheduled 9-12 months out. My gut feel is that what the business is being held responsible to do compared to what IT is being scheduled to do is at times, misaligned. This is not necessarily the fault of IT but rather the business leaders (in which IT should have a seat at the table).
From an operations and manufacturing perspective, we automatically know that it's standard procedure to have a lengthy-but-calculated process for launching new products to the market. Yet, there's perhaps somewhat less frustration with operations & manufacturing on these timelines compared to the frustration I commonly witness with IT scheduling. How can this be?
The business doesn't understand IT
Business users simply don't understand what they can't see. Operations and manufacturing have the luxury of producing physical products and business users can see the progress of this development and can visually comprehend the effort that's put into a product launch.
The challenge for IT leaders is to visualize the various IT processes, illustrate how they plug into the rest of the organization, and be viewed as an ally to projects and not a barrier to entry. It pains me to think how many projects are killed in the course of 12 months because IT resources are required.
Business users need a scorecard for IT projects
Business users need help -- they can't be faulted for not understanding IT, their lack of understanding is on the shoulders of IT leaders. Business users need a scorecard to appropriately rate their projects. There will be some things that internal IT cannot do in the amount of time required. But this doesn't mean "kill the project!" It may mean outsourcing the project to another firm under the guidance of IT.
Unfortunately, many IT shops are one of the following:
- Run as if all IT-related ideas should be their own. This translates to extended timelines and lost time-to-market as IT puts the stops on a project because it wasn't "their idea."
- Operated under the watchful eye of a CFO. This translates to IT operating under the perception that "spending money = bad".
What's an IT leader to do?
- Openly share your project pipeline (disguising projects that are sensitive, if necessary). The business as a whole needs to understand what projects are in the pipeline. If they don't, they will approach you without any context to why your team is so busy -- which is a problem.
- Openly share the methodology for prioritizing projects with the business users who are submitting the requests. This will help them understand the process so that when they come to you with future projects, they will be armed the right data...and not with a preconceived notion that the project will "take a while" because "IT is always busy." Knowing the "why" behind project prioritization goes a long way.
- Accept the fact that you are not all-knowing. It's OK for business users to come to IT with a new idea. You're responsibility is leveraging technology to solve business problems and bringing their idea to life. Without you, it's just an unrealized idea.
- Spending money is not a bad thing. If you report to the CFO, the CFO is not against spending money. The CFO views business differently and is looking at the return on investment (ROI). If you cannot put in requests for money which outline the ROI, then be prepared to have many of your projects denied.
- Don't forget to position yourself as a "go to" person.
Enterprise apps should mirror consumer apps
In this post about "Why Gen Y Is Going to Change the Web" from ReadWriteWeb, the following comment was made:
Work Tools Need to Mirror Web Tools: Gen Y will drive adoption of "Enterprise 2.0" products and services. Gen Y in the workplace will not just want, but expect their company to provide them with tools that mirror those they use in their personal lives. If socializing on Facebook helps them get a sale, then they're not going to understand why they can't use it at work. For more buckled down companies, if workers aren't provided with the tools they want, they're going to be savvy enough to go around I.T.'s back and get their own.
I couldn't agree more -- this thinking (expecting a company to provide tools to mirror tools in personal lives) is already prevalent today in the enterprise and it's not even specific to Gen-Y'ers.
When users find their own way...IS can't add value
I have an interesting perspective starting on the marketing side of the business and building up a website from scratch all without the help of IT/IS. The autonomy and flexibility we had to spend on innovation against a marketing budget was considerably different than having to jump through the hoops of IT layers in the enterprise.
Now that I have transitioned to a new role in the IS department, things are slightly different as I find myself combatting the very actions I was deploying when I was in the marketing department -- employees working around IT's back.
You aren't issued a company cell phone from the model year 2001, so why should the web applications be any different?
I think the Enterprise 2.0 movement will be an important one. As consumers become more web-savvy, so will employees. Enterprise applications and development will need to quickly catch up to the speed of consumer applications and development.
After all, when we get a company-issued cell phones, we don't expect to have a phone that's representative of something from 2001. Why should web applications be any different? One may argue that you "don't fix what's broken." While I love that principle, at the same time, a cell phone model from the year 2001 may not be broken, but there's certainly a more efficient way of doing things today.
Put up roadblocks and employees will work around you
Frustrated employees will find their own ways of doing things and bypassing applications and processes in favor of a more pleasant and easy experience...or they just won't use the technology at all. IT/IS departments will have a revolt on their hands in the coming years if they don't begin to adopt consumer-oriented technology and applications.
Asking “why?” can go a long way – improving business processes
This post about business processes as a competitive advantage hit home for me (it references a poor experience with an airline -- which I'm sure we're all familiar with). I am often jokingly ridiculed for how often I ask "why?" when evaluating internal business processes and the way data is organized in the enterprise. Quite often the answer is surprisingly, "I don't know, that's how it was done before I got here."
In the link above, the same is true for the airline industry. It's as if the entire industry was designed for an ideal world where there are no mechanical malfunctions, bad weather, or delays. Contingency planning and business process optimization go such a long way to improving operational efficiency and most importantly, customer satisfaction. Revisiting pre-existing processes is also a great way to find the low-hanging fruit of improvements.
When building any new business process or system, I find that the following question is helpful to ask over and over during the planning phase: Does this process add value for the end-user?
Such a simple question can go a long way to avoiding a situation like in the above post/link.
Blog by Eric Long
I'm an experienced online marketer, information architect, digital strategist, and social media enthusiast. I'm passionate about providing outstanding cross-channel experiences for considered purchases (with a focus on mass customization).
About Eric Long
Recent Tweets
- New blog post: Mass Customization, Considered Purchases, & Mental Models - Why Usability & Content Strategy Matter http://t.co/ABOwvq1Z 1 month ago
- Looking for a Manager of Web & App development to come work for us and manage a team of Sr. PHP & Ajax Developers: http://t.co/16BhmKjx 1 month ago
- UX Practitioners Will Excel in an Increasingly Digital World: http://t.co/QH6cgr5 5 months ago
- UX practitioners have bright futures with more & more marketers needing help understanding relevancy for when/why to use new technologies. 6 months ago
- We're looking for a Manager of Interactive Design & UX to come work for us: http://t.co/0U1AbN8 7 months ago