This post takes a closer look at the evolution of project controls as discussed in our published paper Project Controls 3.0.  While the modern context of the names project and project manager are relatively recent, project-like endeavors have been undertaken for millennia and needed managing and controlling. Both these earlier endeavors, and modern projects can be viewed as an organized undertaking to deliver a predefined objective, within some level of time and cost constraint[1]. The degree of definition attached to each of these parameters is, and always has been variable, depending on intentions of the client, and the nature of the work being undertaken.

Over the last 4000+ years, the controls mechanisms used to keep the project on track to achieve its objectives have changed significantly. The three major phases of project controls are described below, with a discussion of an emerging stage – 4.0 included for completeness[2].

Project Controls 1 – Static Tools

The earliest controls tools appear to have been models and drawings showing what was expected to be achieved, usually accompanied with some level of agreement as to the time and cost for completion. The design of the Cathedral Santa Maria del Fiore in Florence was in the form of a large model. After the main part of the building was complete, a separate design and model for the dome was made in the 15^th century[3]. There are indications models were used in the design of the pyramids, and architectural scale models continue to be an important element in the architectural design process[4].

In parallel with the three-dimensional models, various pictures and written descriptions of the project deliverable were also common and appear to date back to at least Roman times, probably earlier.

The construction of naval vessels for what became the Royal Navy shows both trends. Mathew Baker (c.1530-1613) was a royal master shipwright under Queen Elizabeth 1st, and an important figure within the small but developing naval establishment. His manuscript known as Fragments of Ancient English Shipwrightry is an early example of complex design being developed on paper[5].

Whereas the National Maritime Museum in London has a 1:48 contemporary skeleton model of the St Michael (left), a 98-gun warship built by John Tippetts and launched at Portsmouth Royal Dockyard in 1669. This is possibly the oldest model that can be connected to a specific vessel. By 1716 the British Navy Board had ordered that all ship proposals for new vessels and repairs to be accompanied by a scale model[6].

These developments allowed the people funding projects, and the people building the project to understand what was expected to be delivered. It was also common for the cost to be agreed and a timeframe for delivery set before work started. However, how the work would be accomplished and managed remained tacit knowledge handed down from one master builder or shipwright to his apprentices. Bookkeeping has its roots in the 14^th century, but it was not until the 18^th century ways of visualizing time started to emerge and the transition of these general practices into project controls is far from clear.

However, by the 19^th century a range of paper-based project management and control tools were emerging many of which are still used today[7]:

• Bar charts were in use by 1765, they started to be applied to projects in the mid to late 1800s.
• Orthographic projection (used for engineering drawings) was described in Géométrie descriptive (1798)
• WBS and OBS Charts were developed in the 1850s
• Project cost charts in the early 1900s.

These had merged into a comprehensive project controls process by the 1930s[8].

The limitation of these developments was the static nature of the information.  The project manager could see what was planned, could measure what was achieved or spent, and see the variance between the two. However, the controls system could not (without a manual recalculation) predict the consequences of the variance. It required the development of computers in the 1950s to make project controls dynamic.

Project Controls 2 – Dynamic (2.X)

The second phase of project controls was driven by the development of dynamic project control tools. This started in 1957 with the development of CPM and PERT scheduling software[9] and has continued through to the present time. EVM was standardized in 1960s[10]. Monte Carlo and other risk tools became available on personal computers from the early 1980s.  

These dynamic tools have a number of common characteristics:

• Data is entered into a software tool and the result is calculated by the tool
• If a parameter or data point is changed, the tool immediately recalculates the results
• The calculations can be modified and influenced by the user, but the recalculation tends to be a ‘black box’ – the user can see the result, but not the incremental steps in the calculations
• These tools can hold and process vast amounts of data very quickly.

Project Controls 2.0 has developed into a sophisticated process with a focus on detail, needing highly specialized experts to run the software. It is not uncommon on a major project to see contractual requirements for a fully detailed schedule and cost plan for the entire project duration to be finished and approved within weeks of the project commencement. The responses to project failures have been to require even more detail in the various controls systems[11]. In the last couple of decades, this trend has fragmented into multiple different approaches to controlling projects - Project Controls 2.X.

Project Controls 3.0 – Adaptive  (PC-3.0)

PC-3.0 is designed to use the 2.X tools developed in the last 60 years within a consistent framework to produce useful management information regardless of the management approach and tool set being used on the project. The technique is equally effective on agile projects, predictive traditional projects, and projects combining element of both.   

PC-3.0 is focused on using the planning function to support accelerated delivery, and to allow different ways of working in a complex environment. This is achieved by focusing on the future work, rather than what has happened in the past. This fundamental refocusing of controls towards improving future outcomes is essential if project teams are to make effective use of the emerging Project Controls 4.0 technologies.

Project Controls 4.0 – Integrated

Project Controls 4.0 is already starting to emerge and is likely to become the dominant paradigm within a few years.  Project Controls 1 through 3 are inherently stand-alone systems that use project data to calculate results. The data transposition between the project systems and the control systems may be semi-automated but they are essentially different tools run by different people.

The rapid emergence of AI, 3-D printing at scale, the IoT (Internet of Things), robots, etc., means that in a relatively short period of time, software systems will be working with people to direct the performance of work across all types of projects.

At the moment, technologies such as BIM 10[12] and digital twins show how project elements interact and what needs to be done, and remote sensing can automatically measure what has been accomplished, but these tools do not directly control the work.  Within a few years we can expect embedded controls to become an integral part of the project digital twin. Seamless data, enhanced by AI, will provide virtual real-time access for all.  This future will require a major refocusing of project controls effort from obtaining and managing data, to analysis, and using these insights to optimize future outcomes.

Summary – Phases of Project Controls

While the phases outlined above are described as discrete steps in the evolution of project controls, the reality is almost all can be found in use in different projects:

• Both static bar charts and architectural models are still common showing Phase 1 concepts still have value in some situations.
• The current practice for most major projects is at the Phase 2 level of sophistication. However, as discussed in the section below, the cost and complication of running a project using Phase 2 systems is fragmenting the project management discipline.
• Phase 3 controls are designed to overcome many of the problems and reframe the practice of project controls using current technologies. The paradigm shift in approach needed to implement Project Controls 3.0 is also a good foundation for the future.
• Phase 4 controls are starting to emerge and are predicted to be the future.  No one knows precisely how this will develop, but it is highly likely that the majority of the work done by, and software functions currently used by, project controllers will be embedded in the project’s digital twin. The controls and management skills needed will be focused on problem solving and optimization.

For more on Project Controls 3.0 see: https://mosaicprojects.com.au/PC-3-00-Overview.php#PC-3-Overview  

[1]    A more complete definition of a project can be found at:
https://mosaicprojects.com.au/PMKI-ORG-035.php#proj-definition

[2]    This classification framework updates our 2015 blog post The three phases of project controls. Phase 1 in both papers are aligned, but the remaining phases in the 2015 blog are incorporated in Project Controls 2.0 in this paper. Read The three phases of project controls:
https://mosaicprojects.wordpress.com/2015/01/06/the-three-phases-of-project-controls/

[3]    For more on the Cathedral Santa Maria del Fiore see Project Management in the 15th Century: https://mosaicprojects.wordpress.com/2023/02/07/project-management-in-the-15th-century/

[4]    For more on communicating design information see Understanding Design - The challenge of informed consent: https://mosaicprojects.com.au/PDF_Papers/P186-Understanding_Design.pdf

[5]    For more on Mathew Baker see The Origins of Bar Charting: https://mosaicprojects.com.au/PDF_Papers/P182_The_origins_of_bar_charting.pdf

[6]    Discussed in The Origins of Schedule Management: https://mosaicprojects.com.au/PDF_Papers/P202_The_Origins_of_Schedule_Management.pdf

[7]    See The Origins of WBS & Management Charts: https://mosaicprojects.com.au/PDF_Papers/P207_WBS_History.pdf

[8]    See the USA Government report on the Wheeler Project:
https://mosaicprojects.com.au/PDF-Gen/The_Wheeler_Project.pdf

[9]    For more on the history of:
-  The Critical Path Method (CPM) see:https://mosaicprojects.com.au/PMKI-ZSY-030.php#Overview
-  The origins of PERT see: https://mosaicprojects.com.au/PMKI-ZSY-030.php#Process2

[10]  For the history of Earned Value Management (EVM) see: https://mosaicprojects.com.au/PMKI-ZSY-020.php#EVM

[11]  For discussion on the problems with excessive detail see:
-  The Planning Paradox, How much detail is too much?
    https://mosaicprojects.com.au/Mag_Articles/AA022_The_Planning_Paradox.pdf
-  Estimating Fallacies – excessive detail does not help
    https://mosaicprojects.com.au/PDF_Papers/P145_Estimating_Fallacies.pdf

[12]  Building Information Modeling 10D: https://mosaicprojects.com.au/PMKI-ITC-011.php#BIM