Enterprises commonly overpay for technology projects. Some companies pay as much as 20% or more because they don’t have a reliable way to estimate the cost of a technology project prior to signing on the dotted line. In the case of larger projects, the impact of this estimation gap can be in the tens of millions of dollars.
Here are five ways to improve IT project estimations that will help you close the budget gap.
The Traditional Project Estimate vs the Project Benchmarking Estimate
IT project estimating is the process of predicting the cost, duration and amount of effort for a project in support of overall cost optimization to value received. Project estimates are used in a variety of situations: 1) preparing budgets for project portfolios (even when the project is agile), 2) demonstrating the prudency of service provider bids and proposals, 3) negotiating best and final offers, 4) validating the cost of change orders, and 5) monitoring the “performance” of project teams and their outcomes.
IT project benchmark estimating (PBE) adds in one critical aspect – comparison to market and industry standards using a top-down approach with a vast database of comparative projects. This data-driven approach ensures a cost-optimized project.
The Traditional IT Project Estimate
Traditional IT project planning and the corresponding management of the project have long been standardized using a multitude of project management methods including agile, waterfall, SCRUM, PRICE2, Lean, Six Sigma, Critical Path Method (CPM). Project Management Professional (PMP) and Certified Associate in Project Management (CAPM) along with the Project Management Body of Knowledge (PMBOK) all provide best practices, standards and procedures for planning and managing projects. But much of this “body of knowledge” is simply that – a body of knowledge and not a specific methodology.
Project Planning and Management (PPM)
Often, the only information available to the business and project team is the requirements (business or technical) that need to be fulfilled, a high-level business case, time constraints, business units involved and the expected level of participation of internal resources. From this point, the project planners work to develop a set of milestones and a framework with critical paths to accomplish the outcomes needed. This approach is often done in a bottom-up approach.
Figure 1 Project Planning (Image created by Microsoft Image Creator)
If the project is to be agile or hybrid as opposed to waterfall, then the development of a framework is challenging since the work from end to end may not have been envisioned or even developed. The desired outcome of project planning is a well-defined, agreed upon and executable plan. These project plans do provide the cost but can span a wide range of duration and effort.
This method of estimation varies greatly as the experience of the group varies and the corresponding trends, staffing and duration predictions are fairly subjective when compared to more data-driven methods.
Enter the Project Benchmark Estimation (PBE)
A PBE is developed using similar variables but predicts cost, duration and effort based on empirical statistical data as opposed to the experience of one or two project planners, solution architects or account team members. The PBE’s goal is to provide the cost, duration and effort by comparing what needs to be completed in the project to other data-substantiated models.
Accurate estimates require the team to determine what work must be done, how long it will take and with what level of effort the work has been done in the past. The PBE does just that.
Real Life Case Study
ISG was asked to assist in the negotiations of a substantial transformation project proposed at well over 100 million dollars.
Using a PBE, ISG gave the client the information needed to ensure the negotiated counteroffer to the service provider was aligned with market expectations and accepted.
The end result was ~25% reduction in the proposed fee with minimal scope change.
The Difference Makes a Big Difference
The typical project team estimate using the traditional project planning method does not have a large statistical database of other projects and plans to determine how many people, hours and calendars days are needed. Instead, a typical project team estimate will likely have a very wide rough order of magnitude with many uncertainties. A highly skilled team may be able to work through the uncertainties and adjust the estimate accordingly to say +/- 15%, but, without having the statistical advantage of thousands of project observations, the estimate will likely be inaccurate.
More often than not, a senior member of the team will say, “Well, when we did it at XYZ company, it took $xx million and 23 months.” This is often seen when using an agile approach. Or, conversely in waterfall methods, the planning team will do a bottom-up “task by task” analysis of the roles needed to perform the project. In both cases, the estimate is based on a limited set of knowledgeable people.
Accuracy of the estimate is dependent on the team.
And what is considered inaccurate? Or put more delicately, if unable to make an accurate estimate, what would the range for a rough order magnitude (ROM) be? According to PMBOK, the accuracy of a ROM is -25% to +75% of the expected cost. That is quite a range! To put it in simple terms, how about ordering dinner with the price on the menu being $75 to $175 dollars.
With a PBE, the estimate is based on what needs to be completed at a top-down level instead of the bottom-up approach. This approach supports all types of project methodologies – agile, waterfall, etc.
How To Improve Your Project Estimates
The easiest way to improve your project estimates is the same as planning for any change.
- Determine what type of change is needed.
- Determine the relative level of difficulty, complexity (business and technical) and impact to the organization.
- Determine how to change the current environment, how soon the change needs to take place and what actions will be needed to perform the change.
- Determine who will be performing the actions and the level of globalization (shoring).
- Weigh 1-4 based on the “ability” of the organization to adapt.
In real world of IT project estimating, this approach looks like…
Figure 2 Team Negotiation (Image created by Microsoft Image Creator)
First, determine the type of project being performed – cloud implementation, application rationalization, infrastructure implementations, web development or package design and deployment (think Workday, SAP, Salesforce). This knowledge will drive the types of skillsets and roles needed.
Second, determine the overall business and technical complexity to impact the normalization from the average cost, duration and effort, i.e., specialized skills for a given role might create risk and increase the hourly estimate for that role.
Third, refine the work to be completed. The greater the detail you have about the work to be performed, the more accurate the estimate. Include how much work is brand new to the team, a modification of existing assets or a total reuse of specific assets. If the work can be expressed in two or more ways, like reports, interface, conversion, enhancements, forms and workflows (RICEFWs) or epics/stories and requirements, then consider using an average of these work units.
Fourth, break out what roles you want to perform and where they are to be performed. In other words, know what roles are typically involved in this type of project and decide where (onshore or offshore) and by what group (internal or third party) the roles will be provided.
Fifth, consider the maturity level of the people, process and tools involved in the project and adjust for higher or lower maturity levels.
At the end of these five steps and using a statistically valid prediction model, the estimate should be as objective and accurate as possible (given the type of work – work units).
Assuming you can compare your project variable with a large database of previous project observations, a PBE provides an empirical forecast of the cost, duration and effort leading to a cost-optimized project.
ISG helps enterprises use PBE to plan for and report on their IT projects, so they add more value to the business. Call us to find out how we can get started.
About the author
Dee Anthony
Dee is the Global Lead for ISG’s Project Estimation Service providing prudency evaluations of cost, duration, labor effort, and shoring ratios for projects through independent estimation validations. Dee is also the co-founder of the Collaboration and Experience offerings at ISG and focuses on the Digital, Physical, and Human Workplace. He is a key leader in the development and execution of ISG’s Build vs Buy methodology.
