Project control is supposed to catch the deviation of the project execution from a baseline - the planned time and cost schedule. If deviation is negative, corrective actions shall be immediately initiated.

These two sentences express an established approach never challenged in modern project management.

For infrastructure projects, they are misleading as they hide the true nature of project engineering and the real targets of the project controls.

We should admit that all these things are governed by probability laws - schedule, budget, S-curve. They are incongruent with the baseline notion as a truthful dataset against which all other data shall be compared. Below are three cases of chaotic forces at work.

During the project bidding, the cost of an agitator was taken from the previous project. To the cost engineer, this step seemed very reasonable; the cost represented the truthful real figure. Later the project control caught over-expenditure of over 30%. What happened?

It turned out that only three bidders participated in the previous project, with prices being different by around 15%. The new project engineer specified two impellers as better options, instead of one. It added 20% to the agitator's cost and simultaneously threw the lowest-price bidder out of competition as its design could not accommodate 2 impellers. 

Every fact mentioned in the above example is probabilistic: number of bidders, price difference, coming of a new engineer and his decision, coincidence of the lowest price and design limitations, etc.

Even established mass-scale production may be a source of deviation. In my recent project, big motors of over 750 kW had been ordered from one of the leading manufacturers. All the motors had not passed the factory acceptance test due to overheating. As the cause of this anomaly had not been found, a new batch had been manufactured. It added four months to the project schedule.

The third case is a tender for the 150 MLD desalination plant (India, Nemmeli, 2016). Following it, the tax regime change - an act of God - made ineligible all the five companies that had submitted offers. 

These cases evidence that the project delays and cost overruns may not be a result of sloppy work but rather a skewed picture of the project and its context, mirroring the contractor experience.

We can accelerate the experience build-up by deliberate risk-taking in procurement, manufacturing, quality assurance, outsourcing, etc.

It means that we should be interested in any deviation whether it is positive or negative, non-controllable or triggered by risk-taking.

These random deviations help us solve a problem that might be deterministic in principle. It is what the Monte Carlo method does - it bridges probabilistic and deterministic views on the project cost and schedule overruns.

If the actual performance follows the "pseudo-planned" one, all the stakeholders are happy. But the contractor learns nothing from success. It is an indication that the project targets are set too low, and the contractor lost the project as a milestone on its road to the experience build-up. 

On the contrary, deviations reveal problems we are not acquainted with. If we discover these problems first, we may turn them into decisive advantages over competition. It is where we create the company asset. In other words,

Project controls are a core mechanism for the company experience build-up.

Statistics say that over 70% of infrastructure projects are delayed and above budget. Given this enormous pool of feedback, one may suggest that the contractors of these projects are on a steep rise in project execution know-how.

Not in the least - overruns in terms of size and frequency are just as large today as in the past. A framework for controls is missing.

It was missed in my first megaproject budgeted at US$ 90 million (2003). As it was a ballpark figure, sources of US$ 30 million overrun had been never identified.

What are the core requirements for such a framework?

The framework shall control both cost and schedule as a single whole.
Both cost and time attributes belong to the same object types - physical asset or work. For more insight read my post "Discovering cost and time in the P&ID universe".

The framework shall store historical data on the projects executed in the past. The cost and time data shall be easily navigated, filtered, and compared.
Ease of navigation suggests that these data shall be structured and linked to engineering categories like P&ID items, systems, and work packages.

The framework shall compare the actual performance not only to the planned one, but to historical data as well. The reason is that the data source may be not the current project but the project executed in the past.

It shall produce the projected time and cost data for any P&ID item, subsystem, area, discipline, purchase package, activity, and work package of the project.
This level of detail allows us to compare apples to apples - a virtual plant to the real one. It should be matched by engineering during bidding and the cost estimation platform. In other words,

Cost controls are meaningful if the project execution starts from FEED - Front End Engineering and Design.

It shall automate the cost accounts identification and generation.
Cost accounts represent the basic unit for cost control. It may be broken down into cost elements.  Accounts and elements are related to particular scheduled activity. Cost accounts may include one or more transactions. Cost accounts shall be accessible to subcontractors.

The framework shall automate engineering workloads forecasting and tracking.
It shall forecast the resources' daily load distribution over the entire duration of the project. Such a chart is the basis for resources' naming and load synchronization over all currently executed projects. Secondly, it shall answer how sensitive the project duration is to the resources' availability. Finally, It shall automatically track the user contribution to the project and register the work hours spent on each activity.

It shall generate S-curve automatically.
It is a manual, error-prone, and time-consuming work rarely done in projects below US$ 200 million.

It shall provide means for project contingency structure analysis.
In the projects I participated the contingency was calculated as an across-the-board percentage addition to the base estimate. As underlying project risks are not explicitly linked to contingency, its value does not change whether the project type is EPC or BOO. The project risks are discussed in "Project Risks".

It shall address material and labor costs' escalation.
There exists a considerable time lapse between quotation, acceptance of tender, and commencement of the project execution. If the bidder is committed to a fixed price at the tender date then all subsequent increases in cost during the project engineering and throughout the construction period, must be borne by the bidder unless a provision is made in the quotation to cover the risk of material and labor costs escalation.

You might think that these requirements are unrealistic to meet? Nelson Mandela is quoted as saying "It always seems impossible until it is done". Crenger.com already implemented most of them.