Do Applications Really Erode? Diagnosing the True Causes of System Erosion
by Lynne Wardell

The term "application erosion" was recently coined to explain the phenomenon of decreasing value in a system occurring over time. It infers that applications have life. Unfortunately, the term not only misdiagnoses a common problem but also misses the point.

In most cases, it is the environment in which applications are used and supported -- not the application itself -- that "erodes". This makes environmental erosion the real cause of technology becoming less effective with time.

Examining the terms "application" versus "environment" in light of the erosion phenomenon is revealing. The former focuses on the tool (the application) while the latter focuses on people (the environment). The following example makes this point.

If you taught a child to brush her teeth, you might give her a new toothbrush, some toothpaste and count to fifty each night to encourage her as she performed the act. But if you took the toothpaste away and no longer gave her encouragement, would you conclude that the child stopped brushing her teeth because the toothbrush eroded? Certainly not. You would, hopefully, realize that all those things -- the toothpaste, the toothbrush and the encouragement -- were necessary to help the child perform the desired act: brushing her teeth.

Root Causes of Environmental Erosion

Like the previous example, the roots of environmental erosion lie not in the technology itself but in the failure of an organization and its project implementation process to value the importance and focus of business and technical support infrastructure that is always required to encourage users to assume ownership of the technology.

User ownership ensures that systems operate effectively over time. It also ensures that systems increase, rather than decrease, in value. But because this reality is usually not addressed, diminishing system efficacy ends up being built into the very foundation of the project as a self-fulfilling prophecy.

It is essential to remember that for any IT project, an environment or infrastructure needs to be created to implement the technology. People must be brought together into project teams that consist of users, developers, support people, training, process communications, marketing, sales and many others. These teams must create whatever is necessary (processes, training materials, rollout strategies) to successfully introduce the technology into production.

Problems tend to arise when this essential environment is not extended beyond the life of the project. Not sustaining the environment is as silly as building a house, pulling the foundation out and expecting the house to continue standing. Hence, once the project is over and the team disassembles, the erosion process begins because the foundation has been removed.

A Real-life Project Example

If an organization hopes to achieve strategic or business results from deploying technology, it must provide ongoing user support. This involves putting business and technical support infrastructure in place (people, process, training and tools) to solicit, act on and refine on user feedback over time to improve technology usability and supportability.

I once managed a project that involved rolling out call center environment software to better service customers. Prior to taking over the project, I learned that the application was having serious problems getting off the ground.

When we arrived, users were abandoning the system and going back to using mainframe screens. They complained about how they had to navigate the system and were frustrated by its inconsistent performance. This left them to wonder, with each call, whether they would be able to service the customer.

Our approach to the problem focused on creating an environment where users owned the application and built an infrastructure to support that ownership. Specifically, we built local center teams at each location, comprised of users and local technical support staff that included the following components:

  • Forums where user and local support staff feedback was processed by an application support team, business proponents, training department and application developers on a monthly basis, even once the project was complete.
  • A self-maintaining process for local center teams to stay intact as members moved onto new positions.
  • The local center teams were given the power to reject new releases if applications did not perform to expectations that were clearly defined using specific metrics and thresholds.
  • Users were trained to be subject matter experts, trainers and coaches of their own systems.
  • Users were asked to provide feedback on both the training material and training strategy.
  • Users were brought in to train support teams on how the system is used and why.
  • Local center teams were asked to prioritize functionality to be included in new releases based on their needs and the direction of the business.
  • Technical support teams (local support staff, help desk staff, server operations staff, application support staff, etc.) were trained across the organization on: a) The importance of the application to the business; b) Who uses the application and how; c) The application architecture; d) Troubleshooting tips, tricks and tools; e) Documentation and escalation procedures

Our approach was more than "just implementing the technology". And by empowering users as owners and building the business and technical support infrastructure to support them, we achieved phenomenal short - and long-term results.

For example, our initial goal was to improve system usage from approximately 66% to 80%, with usage defined as the number of account lookups performed per number of calls taken. At the completion of the project, usage was at approximately 80%. Six months after completion, usage rose to over 88% and users validated that they were using the system to better serve customers.

Some may argue that account lookups are not an accurate metric to measure application erosion. If used alone, I would agree. However, the constant feedback provided by local center teams and the data analysis of feature usage validated improved usage of the application over time.

Ownership, whether of a home, car or work-related issue, creates a vested interest on the part of the owner to increase the value of their property. This means that when any application is built with input from those who actually use it, and is constantly refined to meet user needs, it will usually result in users embracing and using the application more with time.

Preventing or Reversing Environmental Erosion

To prevent or reverse environmental erosion, which leads to application erosion, all levels of management must support the ongoing infrastructure that is required to help users become owners of the technology. While it sounds simple, the execution is complex, requiring a philosophical commitment on the part of top management that is often missing.

To minimize environmental erosion, management needs to commit to the sustained and improved usage of technology over time. They must believe that this commitment will result in empowering users and establishing the infrastructure to support that empowerment. The following are ways to create that environment:

  • User Ownership. Create local teams comprised of users who are the owners of the tool. Make sure there is a process in place so that these local teams are self-maintaining. When turnover occurs, the teams take care of replenishing themselves.
  • User Empowerment. Give users the power of the technology. This can be done in many ways, such as allowing users to a) prioritize future modifications, b) provide feedback on issues and challenges that directs support teams where to focus, c) train other users and d) give direction as to how the training should be done. As part of empowering users, foster thinking and change to ensure they steer the technology in the same direction as the business.
  • Support Infrastructure. Build the business and technical support infrastructure to support users and usage of the technology once the technology is in production. This means identifying and putting in place the people, process, training and tools to hear, process and act on direction from the user community.
  • Sustained Empowerment and Infrastructure. Make sure that there is a process to measure the effectiveness of the technology and how it is implemented, including metrics that measure training approaches, usability and supportability. Be sure to use both quantitative and qualitative data.
  • Acknowledgement. Acknowledge and reward users, support staff, developers, trainers and anyone else involved in sustaining and improving the usage and supportability over time!

I have been involved in several cases that followed this model, and the results were magical.

When users and support teams take pride in system ownership they ensured its success -- as long as the environment remained intact. Organizations that embrace this approach enjoy not just short-term returns but also long-term, ongoing improvement of the technology.

Conclusion

Bottom line: focusing on the environment, not the tool, delivers ongoing returns on an organization's original investment that exponentially exceeds expectations. Unfortunately, failing to address environmental causes of system degeneration can have an equal, opposite effect that brings bottom line returns on investment much less than expected.

Now is the time to radically reassess the real human causes behind inefficient, "eroding" IT applications. Too much time and money is being spent to implement technology that ends up squandered on short-lived returns, with the deterioration process commencing upon the completion of the project.

This is not brain surgery. But it does take a commitment that many organizations, unfortunately, do not possess.

Those who understand that applications erode, only because we let the environment erode, have a tremendous competitive advantage over rivals who will be left in the dust, spending and re-spending precious budget dollars trying to push a square peg into a round hole.


Lynne Wardell is the president of Haddon Group Inc, a project and program management firm leading large cross-functional teams to deliver projects that meet business objectives, delivering long term returns on an organization's investment for Fortune 1000 companies. Through Haddon Group's ProjectLeap IT project advisory line, project and program managers can receive advice and ongoing coaching from seasoned professionals to improve project results. Contact Lynne Wardell by e-mail: lynne@haddongroup.com and visit http://www.haddongroup.com/ .

More articles in The CIO Refresher in The CEO Refresher Archives

   


Copyright 2002 - Haddon Group Inc. All rights reserved.

Current Issue - Archives - CEO Links - News - Conferences - Recommended Reading