I’ve seen executives vent tremendous frustration over how past work doesn’t effectively inform a current estimate. Variations and mismatches in the type of work performed can turn a seemingly simple estimate into a nightmare of pitfalls. You’d think that after dozens, even hundreds of projects, an enterprise would have established certain pricing and cost benchmarks that easily plug into different estimating parameters. Unfortunately, that’s not always the case.
You can, however, effectively benchmark your data to build a useful single source of truth that flexibly adapts to construction estimating situations. It takes a plan, time to adapt, plus executive and team buy-in. Below, I present a four-step action plan to initiate data benchmarking; but first, let’s better define how benchmarking really serves the estimator.
First and foremost, benchmarking is a means to validate estimates. This involves looking at unit costs and productivity rates. Benchmarking should also help detect and analyse trends, including price increases over time and unit cost decreases as quantities increase, among others. It should also filter source data based on known parameters, such as facility or client types, or even locations.
Over time, estimators save information from past bids, talk to those who oversaw past projects, and even factor in data from outside sources. Eventually, all this data must be properly coded in a single, accessible repository that allows them to build apples-to-apples comparisons to properly inform winning estimates. That’s the core driver behind benchmarking data: making those connections between similar data points and finding their relevance to the estimate being developed.
Now that we know a little about what benchmarking should do for an estimator, let’s look at that four-step action plan to show us how to get there.
The Four-Step Action Plan for Benchmarking Your Data
Step 1: Develop a coding strategy
Your coding strategy is the linchpin to successful data benchmarking. You need to code things in a way that allows you to create a match between like items. When we talk about like items, we want to make sure we’re looking at both work activities and source projects. As for source projects, keep in mind, for example, whether a project in Western Australia is relevant to, say, a project in South America or Europe. The same can be said in North America. The cost of resources or productivity may be different in the Dakotas as compared to Toronto.
We also want to be able to aggregate and roll up data. You often hear it said that a company estimates at a deeper level of detail than it tracks actuals. The ability to roll up data helps to improve that. Your coding strategy should also consistently define what constitutes a match at the item level and the project level, all while knowing from exactly where we’re getting historical data.
When developing a coding structure, there are three key points to consider. The structure should support:
- Hierarchical scaling of detail
- Quantification of work by using quantities as well as consistent units of measure (the latter may require ratios between primary and secondary units of measure)
- Assumptions regarding materials and third-party services
Ultimately, you’re always working towards consistency. If, for example, an organisation is going to include the cost of concrete as part of its concrete code then it must do that all the time. If that organisation strips out concrete cost and focuses on labour costs and labour productivity, then it might consider another line item for materials. Developing a coding strategy involves coming up with those conventions. Otherwise, taking a mixed-bag approach to codes won’t help.
Step 2: Use the 80/20 Rule
The 80/20 rule in benchmarking data for estimating is simple: identify that 20% of the work you do 80% of the time, or the things you’re doing day in, day out. Then let that work be the
environment where you build out your coding strategy. As you develop and refine that strategy with this core work, implement those lessons to the 80% of the work you only do 20% of the time.
This is typically the biggest stumbling block I see for customers. They wonder where to start. You’re not going to go into a room at noon and come out at 15:00 and have your coding strategy all done. You’ll need to get feedback and buy-in from people throughout the organisation, and you’ll get that by focusing on your bread-and-butter work, first. The more stakeholders understand the coding strategy and how it’s helping with your primary business, the more they’re going to work with it.
Step 3: Stress consistency throughout the organisation
I’ve heard the quote, “A good plan well communicated throughout the organisation is far better than a perfect plan that has been exposed to a limited audience.” In short, come up with a good plan and make sure people understand it and the expectations associated with it. If stakeholders are not buying in, then adopt the coding structure that allows them to buy-in. And don’t be afraid to engage in discovery to see if, in fact, there’s something you’re missing.
Then, make sure people are always updated. If you introduce new codes or update benchmarks, be sure people are aware of the changes. Continue to work the plan and adjust as necessary. Don’t throw the whole thing out because it’s not working. You don’t have to go all the way back to ground zero to make adjustments.
Step 4: Get started right now
People often feel they’re starting too late. You can’t go back in time, so begin now. Don’t let historical data overwhelm you either. A lot of people ask about legacy data and feel they need to convert it before starting. Don’t do that. Focus on what you’re doing now, on capturing data in real time. Focus on making sure estimates and project controls are coded in such a way that stakeholders can use that data. Once today’s data is integrated into your coding strategy, you can start converting legacy data into some of your codes. You may even set up a parallel effort with what you’re doing now, in real time, to add in historical data.
With a plan, team buy-in and consistent updates to your coding strategy, your benchmarked data will ultimately help you build that trusted single source of truth that company estimators and leaders are looking for. It doesn’t happen overnight, but with effort and persistence, you may find it comes together more quickly than expected.
If you’d like to speak with an InEight consultant about benchmarking your data or learn how
InEight’s estimating software solutions can help, request a demo today.
