How software evaluations can keep your project on budget and on time

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.

Wayferry

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.

Note

• By definition, requirements rated as “Fully meets” do not need any implementation time.
• “Fully meets (option)” or “Fully meets (3^rd 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.