When I witness confusion in the markets we serve, I try to bring clarity to improve the decision-making process. Education is vital to advance our knowledge and improve our systems.
Project delivery is a process. At the start of the process, a project is in an early feasibility or planning stage. At some point, a preliminary estimate, project budget, or target value is established. If it passes an approval gate, the design advances... along with the need for an updated estimate. This process repeats through various stages of maturation. The stage names differ between building vs. industrial, contractor vs. owner—but essentially they serve similar purposes.
Each stage may consist of multiple iterations of a project estimate (e.g., v1, v2, v10). Likewise, each project estimate may consist of multiple contributors (e.g., segregation of work by discipline), multiple alternatives (e.g., add a wing, add a major piece of equipment, deduct site improvements), or multiple sub-projects (e.g., Building A vs. Building B, Offshore platform vs. Pipeline vs. Tank farm).
By now, you should be thinking, “That’s a lot of estimates.” And you would be right. This is where an operational process management system is needed. You need something to manage all that data as the project matures from the earliest stages to the point where you hand it off to the construction team (spoiler alert... you were just awarded another project!). The sausage-making process is often ugly, but you have to manage it if you want to keep your sanity.
We have many clients that generate in excess of 50,000 estimates per year. How can you effectively manage that many estimates without a system?
Now contrast that with a historical data management system that serves as your benchmarking platform. You DON’T want every iteration, discipline, alternative, and sub-project estimate across every stage of the project delivery process. All those references will derail your benchmarking efforts. Searching for data will be slow and cumbersome. Users will be confused when they see the same project fifty times. If your historical data management system has any level of intelligence, the multiple representations of the same project will wreak havoc in your algorithms and wreck your metrics.
Not to mention that your pretty charts won’t look so good. For example, each bar in the chart below represents a single project. How would the chart appear if all the project iterations were displayed?
In a historical data management system, data quality is paramount. You just want the good data (whatever that means to you) in your historical data management system. You want data that you and your team can trust without having to wonder, “Is this good data?” Having a trusted data source that’s rich in history and independent of the sausage-making process enables you to do things you can’t and shouldn’t do with operational data. For example, you can use historical data you trust to validate an instance of an estimate that you build as the project is maturing. This simple sanity check can be the difference between making and losing money on a project.
The project delivery process requires both an operational management system and a historical management system. Confusing the two will take you down a bumpy road.