The complex art of estimating

By Michael Burns

Few complex projects are undertaken without some estimating being done. Whether it’s a construction company that needs to do a custom project or an accounting firm that needs to prepare a proposal for a complex audit engagement, someone (often several people) will have to take a stab at calculating the effort and cost required to finish the job.

As common as it is, estimating is a complex art. I know this from experience, because I have been doing it ever since I worked in a software firm many years ago. At the time, I was responsible for estimating the time needed to develop a new program or set of programs. In the early stages, when we had only a high-level specification or a conceptual design, we would offer a broad range of times to get the job done. But once we had detailed specifications, we could provide a more precise estimate. We did this based on both our experience with similar programs and the complexity of the specification. We used a number of criteria in the specification to arrive at the time it would take.
Today I use a similar method when providing quotes to review a company’s business processes and/or help it choose a new system. I base my figures on history as well as on one complexity metric — namely, how many interviews will be required. The number of interviews is a good metric to judge complexity and it can be easily measured. This comes in handy as our projects are billed on a fixed-fee basis according to the number of interviews. We would only request a change in fees if many more interviews were required than originally estimated.

In our system selection projects, our clients naturally want to know the total cost of ownership, which includes the licence and the vendor’s implementation services. The licence is relatively easy to estimate based on the number of users, but implementation fees are harder to pin down. In their quotes, vendors usually calculate them as a ratio of licence fees. For a relatively straightforward implementation, the fee would be about the same as the licence cost; if customizations are expected, it could be double that amount. Often, however, vendors don’t know enough to assess the complexity of the implementation. They might provide a fairly low estimate but qualify the number based on assumptions. For example, they might assume they will be implementing best practices, which is code for no customizations or variations.

To help assess the reasonability of implementation estimates, we often ask our shortlisted vendors to break out the costs of their services by module and by tasks. Modules would include general ledger, financial reporting and accounts payable. Tasks would include training, project management, setup, reporting, customization, integration and conversion. We also ask them to estimate over five years, as there can be additional costs when a new version is released and an upgrade is required.

Once we have decided on one vendor or solution, we try to nail down all the costs for the implementation. This is not easy, as the vendor will still have questions about requirements and who will be doing what. We typically recommend the preferred vendor be paid a fee to conduct a needs analysis before any licences are purchased to ensure they understand the project requirements. The vendor will then be able to prepare a firm quote and project plan.

No one wants to find that the actual fees to complete a project will be much higher than estimated. It’s clearly not good for the customer, but it’s also not good for the vendor. An unhappy customer is unlikely to give a good reference in future. My advice is to prepare an accurate estimate based on specific criteria that are agreed upon in advance. This will help avoid cost overruns and delays.

Michael Burns, MBA, CA.IT, is president of 180 Systems (www.180systems.com), which provides independent consulting services, including business process review, system selection and business case development. Contact 416-485-2200; mburns@180systems.com