Whether it is in the cloud or the data center, so often enterprise software takes much longer to implement than expected. There are three main reasons for this.
1. Unknown requirements
New requirements are discovered during implementation that should have been found during the analysis. When these new requirements are found, the organization must decide what to do with them. If they are weighted as important or higher, the consultants must determine how to implement them: by configuration, writing code, business process re-engineering, or adding new modules or third party products. All of this takes time, and when too many new requirements are found implementation schedules slip.
2. Unimplementable requirements
The second problem is caused by requirements that are not written to be implementable. Usually, this means the requirement was written at too high a level and without enough detail. For example, suppose one feature desired from the new software was the ability for users to complete and sign a form on a tablet. The requirement was written as “Has mobile app.” When work started on that part of the implementation, it was discovered that while the software had a mobile app, that app did not include the ability to complete and sign a form. That meant new and unplanned work to create an app that would allow forms to be completed and signed on tablets. Again, resolving un-implementable requirements causes schedules to slip.
In both cases, it is the extra work caused by slipping schedules that will drive up costs. Furthermore, to meet schedules, things get left for “phase 2,” which causes business disruption when the software goes live. That business disruption can have a serious effect on the bottom line, as athletic apparel maker Finish Line found out when it upgraded its supply chain.
Both unknown requirements and unimplementable requirements are caused by an inadequate requirements analysis, and both of those problems result in extra unscheduled work that causes implementation delays. It is not uncommon for implementations to take 50% or 100% longer than planned. That means if your implementation was budgeted at $1 million you might end up paying $1.5 or $2 million. (Scale these numbers up or down as appropriate for your project).
3. Selecting the wrong software
The third problem is that of selecting a square peg for a round hole. The goal of any software evaluation is to find the software that fits your business like a glove fits your hand. If you are going to the theater, you don’t want a boxing glove or a snow mitten! An inadequate requirements analysis can result in selecting software that is not the best fit for your organization’s needs, which adds unnecessary delays to the implementation.
The root cause of these problems is an inadequate requirements analysis. Many organizations view the requirements analysis as a necessary evil but have no idea of how important it is. They do an inadequate job, and that results in substantial overruns of the implementation budget.
For example, employees responsible for the requirements analysis will still have their normal jobs but are expected to complete the requirements analysis in a few months by squeezing in that work. Guess what? You are asking too much of employees. Because they don’t want to disappoint you, they do their best, but it isn’t sufficient. You need to dedicate resources to the requirements gathering for several months. Even if there are dedicated resources and those resources are excellent project generalists, they don’t have the requirements analysis skills. Some companies might outsource requirements gathering and then end up selecting a vendor that has a vested interest in the outcome.
The result in all cases is the same: an inadequate requirements analysis that causes the implementation to take much longer than expected. Cutting costs on the requirements analysis is a false economy.
- Requirements will be found either in the analysis or during the implementation. It is just that they cost much more to satisfy when discovered later during the implementation. As part of the requirements analysis, use the process of reverse engineering to discover all requirements, even unknown ones.
- Write requirements so they are implementable. Remember, you are not writing requirements to develop software, but you do need to write them in enough detail so the purchased software can be properly implemented.
- Use a gap analysis to measure how well the software meets your requirements. Select the software that fits your needs like a glove fits your hand.
- If you hire external consultants to do the evaluation, ensure they have no financial interest in the software being selected. Best practice is to avoid using consultants who implement software because they can only recommend what they know. Rather hire consultants who have a data-driven software selection process.
The primary cause of software implementations taking much longer than planned is an immature software evaluation and selection process. Investing in an adequate requirements analysis can return handsome dividends in the form of implementations that finish on time and within budget, and have minimal business disruption when going live. And isn’t that what you want from every major software acquisition?
This article is published as part of the IDG Contributor Network. Want to Join?