Tag Archives: cost estimates

Is the Price Right? “No surprise” cost estimates


“Well, maybe up-teen zillion was too general a cost estimate” – Chris Wildt

Besides defining the project scope and attracting qualified people, estimating project cost can be quite a complex task. What are some of the measures that you can implement to be more certain about the accuracy of cost estimates such that little to no surprises come on your way?

The first measure is to make sure that there is a well-documented specification of the deliverable, whatever that deliverable maybe. In order to get there you must have a breakdown of the product or service that the project will deliver. And because that breakdown is subjective to change, you have to maintain it. At times that can result in change requests from the vendor. Document and document. Although it may not be an attractive tasks to do, overtime it certainly pays off (think for example of business process management and solution sustainment).

The second measure is about process. You need to define the delivery process as well as the scope, cost estimation and configuration management processes. The delivery process requires involvement from the subject matter experts, as they are the most knowledgeable and experienced of how a deliverable will be created. The project leader acts in this situation as a facilitator and involves all key players, from designers to developers to testers up to staff who sustain the solution. They all must come to a mutually agreed to delivery process, that becomes the standard. Periodically review the delivery process and make improvements. When the input is right (specification) and the delivery process is right, the output will meet your expectations. The scope management process is critical for a number of reasons. It tells the sponsor and other business stakeholders what the planned project outcome is in a ‘tangible manner’. Furthermore it forms the baseline of project plan, budget, and the contractual agreement with the vendor. The cost estimation process must be standardized such that all parties understand their roles and responsibilities, and what is required to come to an agreeable price. Full transparency of how the team calculated the estimate is crucial (for simplicity, I am making the assumption that cost and price of a deliverable are the same). And lastly, the configuration management process is important as it sets you up for long term success. If you keep track of the cost associated with the build up or configuration of the product or service, it becomes a reliable benchmark for future requirements. Let’s say for example that a dashboard with operational key performance indictors is a deliverable. Keeping track of the estimated and actual cost, helps you in the future when there is a similar business need. It all sounds very straightforward, but there aren’t many organizations who do it.

The third measure is to include calculation models for cost estimates of deliverables in the contract with the vendor or in an agreed to project standard. Here is a good example: vendors (system integrators) who design, build, test and implement ERP solutions, use standardized models that calculate the level of effort for certain development objects like workflow, reports, interfaces, conversion programs, enhancement programs and forms. Depending on the level of complexity the estimator says that for a medium complex report, it takes 3 days to specify, 5 days to develop, and 2 days to test, so 10 days of effort in total. It is quite common that the client only hears 10 days of effort and a certain price from the vendor, instead of the full breakdown. Depending on the negotiated, overall price of the project, change requests can become the ‘bread and butter’ for the vendor. Especially in saturated, highly competitive markets, where vendors may come in with a relatively low price and try to ‘recover’ along the way. Depending on the type of contract (see a previous post about fixed price), the status of the project and other factors, vendors respond differently to change request, effort estimation and pricing and at times present an unreasonable cost estimate in the eyes of the client. If it is not managed well, it can lead to major conflicts. Why would we let that happen? Why would we not be fully transparent about calculation models instead? When two parties embark on a journey to implement a technology that in many cases is the enabler to transform the business, it is wise to spend energy on those value driven activities instead of debates, conflicts or disputes about project cost. At the start of the project, get concurrence upon a standard that works for both and that, together with the other measures discussed above, will set the project up for success. Consider using industry benchmarks to validate the accuracy of the calculation model.

The fourth measure is about effort contingency. Oftentimes, the initial cost estimate of a new or changed deliverable is nothing more than an order of magnitude, SWAG or guesstimate. The vendor has to go with the client through the specification process first to understand the detailed requirements, before the estimate can be firmed up. Make sure that you incorporate a mark up for effort contingency in the cost estimate (some extra days). This kind of contingency differs from cost contingency. That’s more of a percentage based on a number of conditions and added as mark up on the total project cost. It’s more a safety net for unforeseen and in principle be ‘untouched’.

So in closing, to better manage surprises on the project cost side, strive for full transparency. Meaning: clarity in defining the business requirements, standardization of the delivery process, scope management process, cost estimation processes and calculation models, and finally using an adequate mark-up for effort contingency in the cost estimate.

Bas de Baat

Program Manager Enterprise Applications, PMP© | Solution Architect