How software evaluations can keep your project on budget and on time
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.
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.
Chris Doig graduated from the University of Cape Town, South Africa with a bachelor of electrical engineering degree. While at university, he founded Cirrus Technology to supply information technology products to the corporate market. The focus at Cirrus was helping companies buy the best IT products for their particular needs. Cirrus also developed custom software for the South African 7-Eleven franchise holder and other corporate clients.
In the 1990s, Chris immigrated to the United States and worked at several companies in technical and IT management roles: Seagate, Biogen, Netflix, Boeing, Bechtel SAIC, Discovery Communications and several startups. At all of these companies he repeatedly saw software being purchased with an immature selection process. Invariably this software would take longer to implement than planned and cost more than budgeted. To make matters worse, the software seldom met expectations.
Having struggled with software selection himself, Chris founded Wayferry, a consulting company that helps organizations acquire enterprise software. He is also the author of Rethinking Enterprise Software Selection: Stop buying square pegs for round holes. While ERP projects account for much of Wayferry's work, other types of enterprise software acquisitions include CRM, HRIS, help desk, call center software, clinical trials management systems and so on. For Chris, the ultimate satisfaction is when clients report meeting or even exceeding expectations with their new software.
The opinions expressed in this blog are those of Chris Doig and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.