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.\nLike any journey, if you don\u2019t 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?\nFew 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.\nPart 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:\n\nSelect 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\u00a0failed ERP implementation for Marin County in California.\nUncover 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\u2019t know they needed. Again this helps the organization select the best-fit software.\nImprove 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 \u201cGather requirements,\u201d and what that means when done properly.\nBuild 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.\nReduce implementation costs with requirement context. Capturing \u201cwho, why and how important\u201d with each requirement provides vital contextual information to the implementation team.\u00a0Knowing 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.\nAvoid implementation rework. Detailed requirements accurately specify\u00a0needs, which in turn eliminates implementation rework caused by misunderstanding those requirements.\nMore accurate RFP \/ RFI \/ RFQ responses. When vendors respond to a well-written RFP, there is less room for misunderstandings or creative interpretation\u00a0of the requirements. The RFP is a better reflection of how well the software will meet your particular needs.\u00a0The more specific the requirements are, the easier it is to hold vendors to the contract if things go wrong.\nSet 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.\nWrite 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.\n\nThis 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.