Whether they are in the cloud or the data center, software implementation projects are typically problematic. Issues can range from falling behind schedule (see Idaho State Report) or vendors going bankrupt (see Department of Labor article). While these problems are often caused by selecting the lowest cost bid, there are other reasons, e.g. inadequate upfront work, lack of end-user communications, minimal customer acceptance testing, insufficient training and so on. Regardless, the question remains, how can you reduce the risks of exceeding budgeted costs and avoid slipped project dates?\nOne risk reduction technique is to improve implementation estimates. If the project is going to be expensive or take a long time, it is far better to start with realistic estimates\u00a0than to wait until milestone dates are missed and budgets are exceeded.\nWhen implementing software, detailed organizational information must be collected. By moving much of that collection upstream from the implementation phase to the software evaluation phase, you can get far better implementation estimates and reduce the risks of these types of project problems.\nA previous article explains the concept of reverse engineering features from potential products to develop a comprehensive list of requirements, the primary way of uncovering unknown requirements. Another article explains why it is worth taking the effort to do detailed requirements analysis when selecting software. Part of the selection process is performing a gap analysis between the organization\u2019s requirements and potential products. In doing this, you might use a table like the example below to rate software products against requirements. You can find a description of scoring RFPs against requirements here.\n Wayferry \nAn example of a Product Ratings Table\n\nWhen evaluating software, products are usually assessed until enough reasons are discovered why a particular product is not a good fit, at which point that evaluation stops. However, the selected product is typically assessed\u00a0against most requirements.\nTo improve the accuracy of estimates, ensure the selected product has been assessed\u00a0against all functional requirements rated as \u201cImportant\u201d or higher because those ratings are used to calculate implementation costs.\nThe key to accurately estimating the implementation costs is to extract the different ratings, and for the vendors to use that information for their estimates.\nExtract all requirements rated as Fully meets (config). This list tells the implementation team exactly what they must configure to meet your requirements. They can estimate how long it will take to configure the new software to meet these requirements, and how long the customer acceptance tests should take.\nExtract all requirements rated as Fully meets (code). This list tells the implementation team exactly what code must be written to meet your requirements. They can estimate how long it will take to write that code, and how long the customer acceptance tests should take.\nNote\n\nBy definition, requirements rated as \u201cFully meets\u201d do not need any implementation time.\n\u201cFully meets (option)\u201d or \u201cFully meets (3rd party)\u201d do not apply once a product is selected. Those ratings become either \u201cFully meets\u201d because those items were selected or \u201cDoes not meet\u201d because they were not.\nFor the purposes of explanation, the above table has been simplified by leaving out things like \u201cMostly meets (option)\u201d or \u201cPartly meets (code)".\n\nThe configuration and coding parts of the implementation are usually the bulk of the project work and cost. Included in the information sent to the vendors are the reasons why requirements are important, and how important they are. In addition to improving estimate accuracy, we have found, capturing the who, why and how important helps build end-user buy-in from the early stages of the project.\nProviding vendors with this information allows them to make far more accurate project bids. In addition, adequately documenting requirements\u00a0reduces the need for change orders. Another benefit is that it is possible to measure how well vendors are performing against the contract. In particular, if estimates are shown to be hopelessly optimistic right from early on in the project, this provides warning that the vendor is in trouble. It is even possible to build in contractual protection against hopelessly optimistic estimates.\nBy providing vendors better information on which to base their estimates, those estimates should be more accurate. By measuring vendor progress against those estimates, implementation problems can be detected far earlier in the project, which reduces the costs of fixing those problems.