Large software implementations are prone to failure and for good reason. They are typically long, drawn-out processes that for many are akin to a heart transplant. Over the years as an industry we’ve learned “best-practices” that every organization should apply towards a successful implementation project. Ideas like executive buy-in, change management, RFP consultants, and team participation are all concepts that are well accepted and practiced in most projects today. With all the advances in implementation best-practices you would think software projects are having a much higher success rate. Unfortunately, the data does not support this and if anything, the failure rates are getting even worse. How can this be? After spending the last 15 years serving nonprofits and being part of many implementations, we have observed a number of things that the average nonprofit may not be aware of:
Failures happen all the time, but you likely won’t hear about it
At StratusLive, we’ve had the opportunity to help many nonprofits who have been through failed projects. We’ve also talked and seen many organizations spend double or triple on the planned budget after years of implementation. Why doesn’t the industry know about these failures and what went wrong? What we’ve come to learn is that Nonprofits will not talk publicly about failures as it is a huge loss of revenue, much of which comes at the expense of their constituency. Consultants will not talk about failures and cost overruns because many times they are there leading the nonprofit RFP process that led to the failures. Software vendors obviously will not talk about these projects as it hurts their credibility for the future. This is problematic because it’s difficult to learn from these mistakes and as an industry we seem to continue to repeat them.
Be wary of feature lists
Most of you readers who have been through an RFP are probably aware of the excel spreadsheet full of desired features. Typically, these lists are made up of hundreds of every conceivable software feature you could possibly want with a new system. The problem is many of these features may not directly add value to your organization or even be used. These lists are often recycled from past RFPs that consultants used previously and most of the answers are recycled right back from the vendors. The worst part about it is each feature description are usually one sentence long and can mean different things to different people with all sorts of expectations in between.
Demos can be deceiving
Oftentimes product demonstrations are most appealing when showing the whiz bang of something new and shiny. Unfortunately, the blocking and tackling part of your nonprofit may not make the most entertaining product demonstrations. Many users will assume that these basic processing engines exist and make the critical mistake of thinking “doesn’t every system have these core functions?” We have heard horror stories where these core engines are woefully incapable, and this isn’t realized until AFTER the system is finally live in production.
What’s a Nonprofit to do?
This is something that we have been wrestling with at StratusLIVE since our inception. Software projects are difficult to begin with and the lack of transparency in the industry just makes matters worse. Much of the current RFP process is based on outdated Waterfall methodologies which we believe will be replaced by more modern Agile based approaches over time. Until then, the first step for the nonprofit leader or implementation team is awareness of these pitfalls. Just because that is how everyone does it, doesn’t mean it’s the right way for your organization. Ask tough questions of your consultants and investigate the failed implementations as much as the successes.
