Success or failure in software applications

Our businesses run on application software. Yet the failure of new software applications continues to plague us.

A survey of 158 organizations by Aberdeen group in February and March of this year, has shown another set of issues. The writer describing this in a BLOG, outlines the symptoms, but his perspective also describes the problem. The results of the survey show:

• Nearly 65 percent of respondents reported declines in employee productivity, up from 58 percent in the 2008 survey.
• Just over 60 percent stated that problems with application performance have caused decreases in customer satisfaction, a jump up from 47 percent in 2008.
• nearly 40 percent said that application problems damaged the company's brand, compared with 32 percent in 2008.

Is this kind of performance acceptable?

Part of the problem starts with the writer's opening sentence "Sometimes I forget that selecting, implementing and paying for core enterprise applications are just the first steps in the long and arduous journey of managing the lifecycle of enterprise applications. "

Implementing new application software is not about software, it is about business outcomes. Talking about software projects in terms of selecting and evaluating software as the first steps is the problem. Too many projects get started with the software and end with the software being installed. The software is only a small part of the need.

After implementation, business units are left trying to make sense of the software, become productive with the software, respond to customer needs and continue to sell their products. Unless this is an integral part of "the project", why would you expect anything but dissatisfaction with the results.

Successful software projects need to follow the following cycle:

1. Identify the business goal in concrete measurable terms. This may mean dollars and cents (the most common measure), but also means other business outcomes. For example, improvement in quality of service, faster response time, improvements in productivity may be more easily measurable and will eventually lead to improved profitability.
2. Identify how the software will help you reach these goals. If you just assume that improved results will come, you will be disappointed. New jobs, new software, revised business processes will initially cause reduced productivity. Unless there is some early return on investment from these new tools, you will cause frustration, reduced performance, etc.
3. Evaluate software based on its ability to best deliver the improvements identified above. Then implement and measure the results based on the imporvements. Leave the financial measures until later.
4. Do not end the project when the software is installed, or even when the technical cleanup is completed. End the project when the business goals have been achieved.

The original blog entry describing the survey can be found here.