When purchasing enterprise software, some organizations wait for the implementation phase to flesh out fully detailed requirements. See the advantages of moving this work to the requirements gathering phase of the project.
To some degree, purchasing enterprise software is a journey into the unknown. When projects start, organizations have only a very general idea of what they want and the problems the new software should solve. As the project continues through evaluation, selection and implementation, organizations learn more about their needs.
Like any journey, if you don’t know where you are going, how will you know when you get there? How will you bypass expensive detours like scope creep along the way? How will you avoid a project that does not deliver close to the promised ROI, or even an outright failure?
Few organizations realize that a thorough requirements analysis is the foundation for a successful enterprise software project (see previous article). By the time the requirements analysis is complete, an organization should know what they need in detail, and why they need it. An inadequate requirements analysis sets the stage for a troubled implementation project with ballooning costs.
Part of the problem of ballooning costs is caused by waiting for the implementation stage to flesh out requirements in sufficient detail. However, there are many benefits to doing this work early on in the project, namely at the requirements analysis stage. We summarize those benefits below:
- Select best-fit software. Always compare potential software products against a requirements profile (rather than comparing products against each other). Without a detailed enough requirements profile, organizations risk choosing the wrong product. Dumping the selected software after a failure and restarting the project is expensive and costs soar, e.g. see the article by Chris Kanaracus on the failed ERP implementation for Marin County in California.
- Uncover unknown requirements. A detailed requirements analysis provides an improved understanding of your needs. In particular, the process of reverse engineering features of competing products into requirements (see previous article) helps an organization discover requirements they didn’t know they needed. Again this helps the organization select the best-fit software.
- Improve accuracy of implementation estimates. It is difficult to estimate accurately the time and resources needed for implementing the software when the requirements are written at too high a level. A one-line requirement can encapsulate weeks or even months of work for the unwary. Far better to provide the detail needed to get more accurate implementation estimates. For example, think of how many software selection projects start with “Gather requirements,” and what that means when done properly.
- Build end-user buy-in. Asking the appropriate users to whom the requirements are important, how important they are, and why they are important builds buy-in from those users. This buy-in starts in the early stages of the project when the users see their names being written on the requirements. It makes them feel they have been heard. Projects with great user buy-in have a much better chance of success in production.
- Reduce implementation costs with requirement context. Capturing “who, why and how important” with each requirement provides vital contextual information to the implementation team. Knowing the relative importance of the requirements helps them prioritize their work. Knowing why the organization wants a requirement answers many implementation questions before they are even asked. When the team needs more information, the names of people to contact are listed in that requirement.
- Avoid implementation rework. Detailed requirements accurately specify needs, which in turn eliminates implementation rework caused by misunderstanding those requirements.
- More accurate RFP / RFI / RFQ responses. When vendors respond to a well-written RFP, there is less room for misunderstandings or creative interpretation of the requirements. The RFP is a better reflection of how well the software will meet your particular needs. The more specific the requirements are, the easier it is to hold vendors to the contract if things go wrong.
- Set expectations. When selecting a product based on how well it meets a detailed requirements profile, you have an intimate knowledge of its strengths and weaknesses relative to your needs (i.e. your requirements profile) before making the purchase. Since you know what you are getting, there will not be any disappointments caused by unexpectedly weak areas in the software.
- Write better customer acceptance tests. The more specific the requirements are, the easier it is to write customer acceptance tests against them, and the easier it is to perform those tests.
This list explains why it is worth the effort of a thorough requirements analysis at the start of a project to purchase enterprise software, rather than leaving much of that work to the implementation stage. A future article will explain how to use the evaluation of the selected product to improve implementation cost and time estimates.
http://www.cio.com/article/2910635/enterprise-software/9-reasons-why-you-should-do-a-detailed-requirements-analysis-before-purchasing-enterprise-software.html