An effective way to improve the accuracy of software implementation estimates is to use information collected when evaluating the selected product. Better estimates improve project management and reduce the risks of implementation problems.
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?
One 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 than to wait until milestone dates are missed and budgets are exceeded.
When 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.
A 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’s 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.
|8||Exceeds||Does substantially more than is required. There is room to grow into this requirement, and there is a reasonable possibility the extra functionality will be used at some point in the future.|
|7||Fully meets||The software adequately meets this requirement "out of the box", and no compromises are required. In addition, not setup or configuration is required.|
|6.9||Fully meets (config)||The software adequately meets this requirement when properly configured. No external software is required. Examples are: workflow routing, form or screen layouts, report design, custom fields, setup of lists & categories, user accounts.|
|5.1||Fully meets (code)||The product can fully meet this requirement with a "reasonable" amount of code. Note: the product is designed to support these code gragments, e.g. a macro triggered on a certain event. It does not refer to customizing the source code of the product.|
|5||Fully meets (option)||When optional products supplied by the vendor are added to the base configuration, the software adequately meets the requirement. No compromises are needed.|
|4||Fully meets (3rd party)||The software fully meets this requirement with the addition of a 3rd party product.|
|3.1||Fully meets (customize)||The software can fully meet this requirement with reasonable custom code developed by the purchaser, e.g. by modifying existing tables in the database or by editing product source code. Note: Only applies where the purchaser has access to the source code, and almost never applies to cloud products.|
|3||Mostly meets||The software meets this requirement to a large extent. Deficiencies can be reasonably easily overcome with minimal effort.|
|2||Partly meets||The software has significant deficiencies in meeting this requirement, but they can be overcome with considerable effort.|
|1||Slightly meets||The software has the required feature, but serious deficiencies exist in the implementation that can’t easily be worked around.|
|0.5||Future release||This feature is not currently in the product, but is planned in a future release.|
|0||Does not meet||Product does not meet the requirement at all, or the feature is completely missing.|
When 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 against most requirements.
To improve the accuracy of estimates, ensure the selected product has been assessed against all functional requirements rated as “Important” or higher because those ratings are used to calculate implementation costs.
The key to accurately estimating the implementation costs is to extract the different ratings, and for the vendors to use that information for their estimates.
- Extract 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.
- Extract 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.
- By definition, requirements rated as “Fully meets” do not need any implementation time.
- “Fully meets (option)” or “Fully meets (3rd party)” do not apply once a product is selected. Those ratings become either “Fully meets” because those items were selected or “Does not meet” because they were not.
- For the purposes of explanation, the above table has been simplified by leaving out things like “Mostly meets (option)” or “Partly meets (code)".
The 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.
Providing vendors with this information allows them to make far more accurate project bids. In addition, adequately documenting requirements reduces 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.
By 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.
This article was originally published on CIO.com on April 22, 2015