Case Studies
A quick review of what we can learn from these case studies:
Losers
As you saw in the preceding case studies, the money pit is easily found. Often you don’t realize you’re in it until it’s too late. Most likely the people in the money pit case studies never thought – or at least never planned on – their project ending up in the dark hole. Had they seen how other, perhaps similar projects ended up failing, they might have avoided that fate. Here is what we learned about projects ending up in the money pit:
Unclear ROI or payback based on unrealistic or false assumptions. An unduly optimistic view of projected benefits. Vague promises of thousands of hours saved.
A complex, unproven software solution. A kind of hubris about the sophisticated design the team has developed. A belief that no matter the complexity, the software can handle it.
Technology not easily assimilated by its intended users. Often really smart people who understand technology don’t realize that actual users won’t have that same ability. User involvement from the start can prevent this, but among users there will always be varying skill levels. Keep it very simple.
Unclear requirements or continually changing requirements. Not getting into enough detail about exactly what you want the software to do in each business scenario. Allowing mid-course or late-course changes to requirements without evaluating their impact on the project.
Inadequate vetting of the software leading to delays and extra costs. Buying software based on demos and general high-level comparisons of what you need and what the application can provide. Remember, an application can do anything you want it to, as long as you have enough money.
Big bang cutover without adequate risk management. Not thinking through contingency plans if failures occur on or after launch date. Not willing to consider a phased approach because of artificially imposed deadlines.
Winners
Projects with an unambiguous and demonstrably positive ROI based on realistic assumptions. Project ROI that is vetted and challenged, under different scenarios in case the application doesn’t deliver all benefits as expected.
Technology readily available in the market and proven to work in other enterprises, with limited customization. Ideally a long list of satisfied customers, whose business models and needs are similar to yours. Software that attracts user groups and forums, and for which programming and other experts are available in the market to hire as support for your project.
Full under-the-hood evaluation of the fit of the system with the business. A set of pilot work sessions, with all participants present, where users step through each business scenario using the application.
Narrow and specifically defined scope of implementation; clear and unchanging business requirements. A strong defense against mission creep. Requirements that are documented in detail and that include all possible business situations and exceptions.
A strong, experienced, focused team with a mandate from top management and a simple, clear objective. A team made up of people who have been temporarily freed from day to day business to focus on the project. Ideally several team members who have worked on system projects before. No ambiguity about any part of their mission.