Programs pose a unique challenge for estimators hoping to capitalize on project history. Projects constructed as part of a group or program are often executed in fundamentally different ways than their stand-alone counterparts, which offers economies and efficiencies that do not exist for stand-alone projects.

Consider a stand-alone hotel project and a program that consisted of two identical hotels: Hotels B and C. Hotels B and C shared a single equipment crew and crew mobilization, so they benefited from design and material economies. It’s pretty easy to see that including Hotels B and C in a study to establish the cost of the next stand-alone hotel is complicated.

As I observe companies implementing benchmarking systems, I see them wanting to compare programs more from a finance than an estimating point of view. In the finance scenario, the benchmarking tool is used as a bid adjudication tool or program-level cost estimate report. Rarely would a contractor be called on to reproduce entire cookie-cutter programs made of identical building types and have enough history building those programs to leverage a dataset for developing future programs of the exact same type.

If benchmarking is all about comparing projects and not programs, the data within a benchmarking system should prioritize the support of project-level analysis with project scope consistently organized across all projects. So while the ability to collect program-related projects together in a single view is helpful, strictly speaking, it isn’t the job of a benchmarking tool. That task is better suited to a reporting or adjudication tool.