Projects with clearly defined business objectives can and do fail even if they deliver functionality that syncs closely with the business objectives defined for the project, but do not meet user expectations. This may seem counter intuitive at first blush since the primary purpose of any enterprise software development effort is to deliver tangible financial value to the business. However, user needs and expectations of a product are very different than just the dollars and cents of value contributed by an application. They need to be understood and managed with the same rigor shown to aligning a project with business objectives.
The first and most common area of divergence is usability. Users will reject an application that does not meet usability expectations regardless of the functionality provided. Application teams often make the mistake of assuming that great functionality trumps everything else. In fact, my experience has been the exact opposite. Usability trumps functionality. I would argue that usability is an integral part of the final functionality. This is taken as a given in consumer applications. However, for some reason, enterprise application teams believe just the opposite. While it is true that user expectations of usability of enterprise applications are lower than those of consumer applications, ignoring it totally or treating it as largely irrelevant is a fatal mistake.
The second area of divergence is performance. The mistake made here is identical to the one made around usability. Assumptions are frequently made that performance degradation is a valid trade off for functionality. Real world experience has proven this to be a fallacy. User groups have rejected applications that do not meet performance expectations even when the degradation is not significant or what one would consider “objectively bad.” And, they will continue to do so.
The third area of divergence is poorly communicated process changes. Productivity improvements in applications are almost always accompanied by significant process changes. Teams typically assume that users will make the needed process changes when they see all the great functionality that comes with the new application. Real world observations have proven this assumption to be false more often than not. While this is typically explained away as “resistance to change,” the reality is more nuanced and complex. Process changes will need retraining and in many cases elimination of positions. These are non trivial issues that need to be planned for and communicated clearly. Elimination of positions does not necessarily mean that the impacted employees have to be let go. They are often absorbed into other parts of the organization or perform higher value functions. But if these are not planned for in advance, the only option will be to let people go upon deployment. Confronted with this choice, users will push back and reject solutions.
All the issues identified here are easily manageable. What makes them difficult and causes them to recur repeatedly are commonly held beliefs that these issues do not matter. More specifically, teams do not believe that their project will fail so long as they are delivering value because of the reasons identified here. This is a fatal mindset. And mindsets or belief’s are the hardest to change. If you are working on a project that may have this mindset, it is time to take a long, hard look in the mirror. It is easy to manage these issues up front. But handling them during User Acceptance Testing or an a Go/No Go call is a sure fire recipe for disaster.
