M01-1 Introduction to Managing Project Controls

01.0 - MANAGING PROJECT CONTROLS

01.1 - MODULE 01-1 - INTRODUCTION TO MANAGING PROJECT CONTROLS

01.1.1 - WHAT IS THE PURPOSE OF MANAGING PROJECT CONTROLS?

The purpose of the Managing Project Controls Module is to serve as the GOVERNANCE DOCUMENT to all the remaining processes, defining how they relate to one another and how they interact as a system. 

Explained another way, the Managing Project Controls Module provides an overall “Roadmap” or “Master Plan” or “Framework” to help understand how the modules are organized, what the different conventions or color coding structures show us and how to read and understand the follow on Modules so we can use them to gain maximum advantage or benefit from this document and the context or application of each modules to all the other modules.. 

The Guild of Project Controls Compendium and Reference (GPCCaR) is unique in that it differentiates between the perspectives of both the OWNER and CONTRACTOR organizations, and explains both perspectives, which in many cases are significantly different, either in terms of perspective or procedure. 

To address both the owner and contractor perspectives, the Guild has produced 4 levels of detail or granularity: 

01.1.1.1 - THE "10,000 METRE VIEW"

This is a high level explanation showing the combined Asset Life Span and the Project Life span. This serves to explain how Owner organizations use project management as the preferred option to “create, acquire, update, maintain, expand and eventually dispose of, organizational assets”. Explained another way, for Owner organizations, project management is nothing more than the “means to an end”- a way to achieve organizational tactical or strategic benefits through the use of the project management processes. For Owner’s a project is either an INVESTMENT or COST center (cash out) from which they expect a return on that investment (RoI) or return on asset (RoA) which comes not from the project but from whatever product, service, change or other objective the project was undertaken to create or produce. It is the end product the project has created which generates RoI or RoA through increased revenues, reduced costs, meeting or fulfilling government mandates or increasing intangible value through corporate social responsibility projects. 

This level of detail also demonstrates how contractor organizations fit into the Asset Life Span model, understanding that for Contractor organizations, a project is a PROFIT CENTER- that is, contractors expect to generate a profit from “planning, executing, controlling and closing” projects which were initiated by the Owner organization. 

01.1.1.2 - THE "1,000 METRE VIEW"

This level looks at the how each of the 12 modules relates to all the other 11 Modules. Generally speaking, at this level of detail, we are looking at one or two of the “Key” or “Primary” deliverables that each model produces and how the output from that module becomes an input to the follow on modules. At this level we also show the Feedback Loops, and how those feedback loops serve as a way to achieve “continuous process improvement” through the use of “Double Loop Learning”. 

01.1.1.3 - THE "100 METRE VIEW"

At this level of detail, we introduce each single “step” or “Lego building block” that goes into each of the 12 processes, showing the sequence that is normally and customarily followed “on most projects, most of the time” understanding that implicit in taking the “Lego Block” approach, the sequence can be changed or modified and that it is entirely possible to justify skipping or eliminating one or more of the “Lego Blocks”. This level of detail provides both “scalability” and “adaptability” to the model not usually found in other process maps. It is at this level of detail where we can identify each process as being one of the 5 project management process groupings- 

• Initiation- a process that authorizes or enables the move from one phase to another, initiates or authorizes a project, work package or even a single activity to commence; 
• Planning- a process whereby those who are going to be executing the work invest the time and effort to figure out in advance how they want to execute the project and then are measured against what they said they agreed to do;
• Executing- the process where the work shown in the plan is physically completed; 
• Controlling- the processes where “project controls” plays an auditing role, measuring the work done by others against their work plan; 
• Closing- those processes designed to bring the phase, project, work package or single activity to both physical and administrative closure. 

01.1.1.4 - THE "GROUND or WORKING LEVEL VIEW"

 This level is where we explain in detail:

• Inputs- Specific documents or other tangible or intangible pieces of information necessary to produce the outputs each process was designed to create or produce. Using the analogy of backing a pizza, these are the ingredients necessary.
• Tools & Techniques- These are formulas, templates, procedures, software that are used to transform the inputs into whatever outputs each process was designed to create or produce. Using the analogy of backing a pizza, this would be the recipe, the oven, the measuring instruments and pans necessary to transform the ingredients into the pizza.
• Outputs- These are whatever detailed documents or other tangible or intangible pieces of information that each process was designed to create. Using the analogy of backing a pizza, this would be the finished product which then becomes an input into some other process. (i.e. eaten directly or offered for sale)

While the project control professional is expected to know and understand all 4 levels, the Guild established the standards of competency and will be assessing for competency at the 4th Level, where the work of the project control professional is actually being done.

01.1.2 - WHAT ARE THE PROCESS MAPS FOR MANAGING PROJECT CONTROLS?

01.1.2.1 - THE "10,000 METRE" Process Map Defined and Explained

Project Controls Practitioners (i.e. planners, schedulers, cost engineers / estimators and quantity surveyors etc) all generally apply their knowledge and skills to what we refer to as “Projects”.  We need to be aware that these projects have a longer “Life Span” than the stage(s) where they are tendered, bid and / or build or constructed.  

We all operate effectively as "Time and / or Cost Managers" so it is useful to explain where we sit within the bigger picture...

An “asset” can be described as being “A tangible or intangible resource with economic value that an individual, corporation or country owns or controls with the expectation that it will provide future benefit"¹.  

The GPCCAR covers the use of project management as the preferred delivery system to “create, update, expand upon and eventually dispose” such "assets", or “projects”.  It needs to be noted that such projects could be tangible or intangible; i.e. a physical structure or something less tangible such as software or other business initiative which, when implemented, may provide a service or benefit.  Figure 1 below explains the phases or stages that such projects evolve through.  We can therefore see that Project Controls Practitioners operate at different phases or stages within the overall “Life Span” as follows:

• OWNER practitioners operate within the entire “ASSET Life Span” (i.e. Phases 1, 2, 3, 4, 5, 6 and also 7)
• CONTRACTOR practitioners operate within the smaller “PROJECT Life Span” (i.e. only Phases 3, 4 and 5)

It should also be noted that any analysis and development work carried out by OWNER practitioners within Phases 1 and 2 may never transform into an actual “Project” commencing in Phase 3, thus the time horizon of the Asset Life Span will always be greater than that of any single Project Life Span. 

Figure 1 - The 10,000 metre view of ASSET, PROJECT and PROJECT CONTROL Life Spans 

Source: Giammalvo, Paul D (2015) Course Materials. Contributed Under Creative Commons License BY v 4.0

While there are other professional organization’s which address the management of these projects, the Guild of Project Controls is the leading global organization which represents those who work behind the scenes by supporting managers and project teams (i.e. both Owner and Contractor) in:

• Developing the initial schedules, cost estimates and budgets
• Creating a risk adjusted baseline cost and resource loaded schedule,
• Gaining approval for this baseline, then,
• Measuring physical work progress against the baseline,
• To analyse, report and forecast the progress against the baseline and finally,
• To identify and resolve any claims resulting from deviations against the baseline

As this guide follows the life span of the project from concept through execution, the GPCCAR focuses on the tools and processes necessary to prepare the Decision Support Packages (DSP) which becomes progressively elaborated each time a Phase “GATE” is reached, understanding that not all projects will survive the Phase Gate selection process and move from one Phase to the next. 

To explain this model fully, let’s look at each element from the graphic above:

01.1.2.1.01 - Enterprise Organisational Grand Strategies

Figure 1 Item 1: - Owner organizations undertake projects as the means to achieve some organizational strategic objective, be it large or small. This might be to increase revenues or reduce costs or to build the “brand image” or complying to new laws or regulations. But in an owner organization there is no reason to undertake ANY project other than to meet or fulfill some business need or requirement.

We can see an explanation of how to link projects to achieving organizational strategic objectives in Module 02-6 - Identifying And Engaging Stakeholders.

01.1.2.1.02 - Organisational Policies, Practices & Procedures

Figure 1 Item 2: - One of the concerns we have as Project Control practitioners is the lack in many organizations of Standard Operating Procedures (SoP’s) or “Policy and Procedures Manuals” which help tell us what we are expected to do.  For this reason, in each of the GPCCAR Modules the first “sub-module” is to create a Standard Operating Procedure appropriate to that Module.

Because Standard Operating Procedures are unique to each company, and in fact may be considered proprietary and confidential, no attempt was made to provide specific examples. However templates have been provided to help those organizations who do not yet have any SoP’s in place.

Developing or providing a specific example is highly encouraged. 

01.1.2.1.03 - Stakeholder Expectations - Identified

Figure 1 Item 3:- Identifying stakeholder “needs, wants and expectations” is the key to defining whether or not a project has been “successful” or not. In Module 02-6 - Identifying And Engaging Stakeholders, we have addressed several tested and proven methods on how to go about doing this.

01.1.2.1.04 - Stakeholder Expectations - Realised

Figure 1 Item 4:- In order to measure or assess whether a project was successful or not and to what degree means not only do we have to identify stakeholder "needs, wants and expectations" but at some point, measure those needs, wants and expectations.

The Guild of Project Controls has accomplished this in Modules 03.3 - Validating Stakeholder Expectations and again in Module 3.5 - Accepting Completed Deliverables.

01.1.2.1.05 - The Asset Lifespan

Figure 1 Item 5:- Because Owners are using "projects" as the means to an end to “acquire, create, update, maintain, expand and eventually dispose” of organizational assets, their measurement of “success” is based not so much as whether the project was “successful” but whether the PRODUCT the project was undertaken to achieve was successful or not. That is, did whatever it was that the project was undertaken to produce or accomplish deliver the return as predicted in the original business case? Explained another way, did the product of the project fulfil the organizational strategic objectives? Yes or no?

The relationship between Asset Managers, Operations Managers and Project Managers in an owner organization can be best explained this way:

Figure 2 - Asset, Operations and Project Management in an Owner’s Organization

Source: Giammalvo, Paul D (2015) Adapted from Wideman, Max. Contributed Under Creative Commons License BY v 4.0

In Figure 2, we can see how, from the owner’s perspective, there are "three actors” which are involved in the use of projects as the delivery method of choice.  To explain who those three "actors and the roles they play:

• Asset Manager - is normally a functional manager who is responsible to allocate scarce and / or limited resources (assets) to acquire, create, expand upon and eventually dispose of organizational assets. The asset manager’s primary or key focus is Return on Assets (RoA) and the majority of projects the Asset Manager is responsible for are funded using the Capital Asset Budgeting Process, more commonly known as CAPEX. One of the major roles and responsibilities of Asset Managers is to serve as PROJECT SPONSORS for CAPEX funded projects. Because assets tend to have a relatively long life, the Asset Manager has the longest time horizon. In the case of fixed assets, (i.e. buildings) this is often 35 or more years. In the case of intangible assets, such as the license to operate a mine, it may be 50, 75 or even 100 years. 
• Operations or Program Manager-Operations or Program Managers - are also functional managers usually responsible for a specific profit or benefit center.  The Global Alliance for Project Performance Standards (GAPPS) based on research by Sergio Pellegrinelli offer us a definition of “program” manager:

  

Figure 3 - Research Based Definitions of Program 

Source: Global Alliance for Project Performance Standards (2011) Program Typology

Program Managers run GROUPS of projects which can be funded either by the CAPEX or OPEX (Operating Expenditure Budgeting Process) As shown in Figure 3 above, the example we are looking at is an OPERATIONAL PROGRAM.  Normally, in an OPERATIONAL PROGRAM the projects are funded by the OPEX budgeting process and the Operations Manager is evaluated based on the return on investment (RoI)  

Explained another way, the asset manager invests or allocates scarce or limited  assets (resources)  to the Operations Manager, who in turn is expected to generate a favourable return on those investments.  As the Operations Manager is only responsible for an asset once it has been acquired or created until the end of the assets useful life, his/her time horizon is normally shorter than that of the Asset Manager, who is responsible not only to acquire or create the asset in the first place, but also to dispose of it at the end of its useful life.  Program or Operations managers are usually SPONSORS of OPEX funded projects and CUSTOMERS of CAPEX funded projects.

• Project Manager - in an owner’s organization, normally the Project Manager plays a largely tactical role. His/her job is generally a mid-level management job with little formal authority other than to push to get the project finished on or ahead of schedule, within budget and in substantial conformance to the technical requirements. This is the basis for measuring the success of an owner’s Project Manager. In most owner organizations, the Project Manager has limited authority and most major decisions have to be made by either the Asset or Operations Manager in their role as project SPONSORS or more commonly, are made by a “steering committee”. As the life span of most projects is at most 2-3 years, that is the time horizon of most Project Managers. In an owner organization, rarely is being a Project Manager a career path objective. Normally being a Project Manager is but one step on the corporate ladder to holding a functional position, either as an asset or operations manager.

So where does “Project Controls” fit into this picture? There are three generic organizational structures which are often found.

1. Project Controls works for and reports to the Project Manager directly
2. Project Controls works for and reports to a Project Management Office Manager and serves as subject matter expert to the Project Manager
3. Project Controls works for and reports to the Project Sponsor - either Asset (CAPEX funded) or Operations Manager (OPEX funded) projects and serves as subject matter expert to the Project Manager

While there are pros and cons for each of these methods, because of an inherent conflict of interest in having what amounts to the Project Control team reporting to the Project Manager while in effect, providing an auditing function, the Guild of Project Controls advocates for option 2 or 3 as being less subject to Project Managers trying to “spin” or “massage” the numbers to hide bad news.  

Explained another way, as Project Controls is providing an auditing function, whenever possible they should be as independent from control or influence of the Project Manager, as possible, while at the same time, providing advice and guidance to the Project Manager. This will be explained in more detail when we look at the various Project Management Office structures in Module 01-1 Introduction to Managing Project Controls.

01.1.2.1.06 - The Portfolio of Assets

Figure 1 Item 6:- Assets shown on their owner's balance sheet are usually classified according to the ease with which they can be converted into cash.

Figure 4 - The Portfolio of Asssets 

Source: The Institute of Asset Management; BSI PAS 55

The Figure 4 shows us the "asset classes" and we can see that in most cases, these assets are controlled by FUNCTIONAL Manager: 

• Information Assets are normally controlled by functional groups such as IT or Engineering;
• Human Assets are controlled by HR;
• Physical Assets are controlled by either operations (“plant manager”) or other functional entities such as “heavy equipment shop”;
• Financial Assets are controlled by accounting or finance and lastly;
• Intangible Assets which are defined to be the difference between a company’s book value and market capitalization value is controlled by sales and marketing or public relations departments.

It is the responsibility of these functional organizations to allocate what are often scarce or limited “organizational assets” to projects, understanding that not all projects have the same priority and in many cases, there are too many projects for the pool of existing resources to be able to manage effectively.

For more on this topic, see Module 06.3 - Acquiring Manpower for the Project, more specifically, “span of control”.

01.1.2.1.07 - Portfolios of Projects

Figure 1 Item 7:- A “portfolio of projects” is no different than any investment portfolio, the objective being to minimize the risk and maximise the return. Any organization, be it Owner or Contractor has a portfolio of assets (resources) available to dedicate to projects, with the objective being to develop the best “mix” of projects which will generate the most favourable return on those assets.

For most Owners, projects fall into 4 broad categories:

1. Revenue Generating or “Top Line” Projects - Sales and Marketing Initiatives, New Plant Construction (Capital Investment) o Mergers/Acquisitions/IPO’s (New Market Penetration)
2. Cost Containment or “Bottom Line” Projects - Reorganizations, Outsourcing, Enterprise Software Solutions, Process Reengineering, Project/Program/Portfolio Management Offices
3. Government Mandated Projects - SOX/BASIL II, Environmental Protection o Labor Law Compliance
4. Community Service or “Good Will” Projects - designed to improve the image or credibility of the organization

While Contractors may also have the same categories of projects internally to the organization, as projects are PROFIT CENTERS for Contractors, most of their projects will be revenue generating projects.  

This is very different than Owners, for whom a project is either a cost or in investment center.

By adopting the Integrated Asset - Project Management approach developed, used, and tested for over 50 years by the oil and gas sector, the Guild of Project Controls has been able to create a guide which is relevant and useful to both Owners and Contractors alike.

Using this model, we can see how Project Controls has access to considerable amounts of data, especially in terms of cost, productivity, scheduling, risk and performance which becomes critical inputs to the management decision making process.  

Given Building Information Modeling (BIM) is surely going to impact the practice of Project Controls, we need to become experts in project database management, which is why we have included a module on that topic- Module 11- Managing Project Databases.

01.1.2.1.08 - The Project Life Span

A project is defined to be "an investment that requires a set of logically linked and coordinated activities performed over a finite period of time in order to accomplish a unique result in support of a desired outcome" - Source: Adapted from a Linked In discussion initiated by William R. Duncan  1/13/2018-  https://www.linkedin.com/feed/update/urn:li:activity:6357416976318558208/"

• A project may be simple (making breakfast), complicated (design and construction of a commercial airport), or complex (development and implementation of an enterprise resource planning system)
• As an investment, each project requires a commitment of financial resources, non-financial resources, or both
• Coordinated means that the work of the project is done in an organized way to ensure effective and efficient use of the committed resources
• The finite period of time may be defined in advance as a constraint, determined by planning, or predicted through analysis of actual performance
• Unique means that the characteristics of the result are different in some identifiable way
• The desired outcome is expected to benefit the entity or entities that have invested in the project
• The activities, the period of time, the result, and the outcome are typically described in general terms at the start of the project, then in more detail as the project progresses

Figure 1 Item 8:- As the figure above illustrates, while there may be dozens if not hundreds of projects, either or both CAPEX or OPEX funded over the life of any given asset, the most any single project will take is say 5 years. Compare that against an OWNERSHIP or PHYSICAL life of 30 years or a PRODUCTIVE life of 25 years and we can understand why Project Management in an Owner organization is not usually a career path objective. In most Owner organizations, project management is an obligatory step on the corporate ladder either to an asset managers (functional) position or to an operational management position.

01.1.2.1.09 - The Project Controls Life Span

Figure 1 Item 9:- Project Controls plays an interesting role.  In most Owner organizations, Project Controls is also a step on the corporate ladder usually a prerequisite to being a functional or operations manager or a functional or operational technician. Rarely is it a terminal career path objective the way it is in Contractor organizations.

There are two approaches to being involved in Project Controls, either as an Owner or Contractor’s Project Control Practitioner.  One is to be a specialist, either as a planner, scheduler, cost estimator or forensic analysis / contracts or one can opt to become a generalist, gaining experience in all three areas and becoming known as a Project Control manager, engineer, practitioner or technician.

Generally speaking Project Controls become involved only when a project has been approved and is at least partially funded, shown above as Phase 3, 4 and 5 (or put another way as the “Select", "Define" and "Execute" phases) although they may very well become subject matter experts in the early phases of project development, shown as Phases 1 and 2 (or put another way as the “Identify" and "Assess” phases) or after the project is done, shown as Phases 6 and 7 (or put another way as the “Operate" and "Disposal” phases).

The methodologies and processes for Project Controls will be explored later in this module - Module 01- Managing Project Controls, while the specific tools & techniques Project Control practitioners are expected to master will be found in each specific module. (i.e. Cost Estimating Tools & Techniques will be found in Module 08 - Managing Cost Estimating & Budgeting, while Planning & Scheduling Tools & Techniques will be demonstrated in Module 07- Managing Planning & Scheduling).

Worth clarifying is that the model shown in Figure 1 above is based on the Project Life Span from an OWNER’S perspective. To make the relationship between the Owner’s perception of the Project Life Span and the various Contractor’s perception of the Project Life Span as clear and understandable as possible, we can see above that the owner’s Project Life Span starts from the time a single option has been decided upon and initial funding has been provided internally either through the CAPEX or OPEX budgeting process (i.e. Phase3, the Select Phase) and continues to beyond the end of the project Execution phase (i.e. Phase 5).

If the project is to be executed under some form of Cost Reimbursable contracting strategy (i.e. Design, Build, Engineer, Procure, Construct and Commission (EPCC), Integrated Project Delivery (IPD) or Cost Plus Fixed Fee etc.) the Contractor would likely be brought on board by the Owner during the latter part of Phase 3 (the Select Phase) or start of the Design phase to provide Engineering and Procurement services during Phase 4 (the Define Phase), at which point the Contractor would involve his / her own Project Manager and Project Control Team along with that of the Owner’s Project Manager and Project Controls Team lasting through Phase 4 (the Define Phase, i.e. Engineer and Procure) to the end of Phase 5 (the Execution phase, i.e. Construct and Commission).

If however the project were going to be contracted using a Firm Fixed Price type contract (i.e. traditional Design, Bid, Build, “hard money” or Unit Price Contract) the contractor would more than likely not be bidding on the contract until the end of Phase 4 (the Define Phase) and not start work until the beginning of Phase 5 (the Execution Phase) through to its completion.  One or both of these two latter approaches is the model most Contractor Project Control practitioners are likely to be familiar with.

As Project Controls practitioners, given we may be working for both Owners and Contractors during our careers, it is important that regardless of who you may be working for now, that you know and understand that there is a difference in time horizons for practitioners working for Owners vs. Contractors. And while most of the tools, techniques are similar, Owner’s Project Control practitioners tend to be using more “top down” tools and techniques while contractors tend to use more “bottom up” tools and techniques. The only other major difference is in the level of detail and granularity of the reports being generated. Owner project managers tend require more high level reporting than do contractors project managers, but either owner or contractors should be able to generate reports at any level of detail. To see more on this, refer to Module 07- Managing Planning & Scheduling, Module 08- Managing Cost Estimating and Budgeting and Module 09- Managing Progress.

01.1.2.1.10 - Involvement of Cost Engineer / Business Analyst / Systems Engineer

Figure 1 Item 10:- These functions are often confused with or sometimes part of what a Project Controls practitioner actually does. Theoretically, these people have a broader set of experiences and skill sets with more focus on the business decision rather than on project decisions.

However, from a practical, pragmatic perspective, many Project Control practitioners perform the duties of cost or systems engineers or business analysts and conversely, many cost or systems engineers or business analysts also provide Project Control practitioner services.  Explained simply, the difference seems to be more what phases of the project you are actually involved in rather than any major difference in the tools, techniques or methods employed.

01.1.2.1.11 - The Decision Support Package (DSP)

Figure 1 Item 11:- This is the set of documents which must be prepared for review by management before making the decision to move a project forward from one Phase to the next.  Providing data, calculations, and input as subject matter experts in the preparation of Decision Support Packages is one of the primary roles and responsibilities of the Project Controls team.  Normally the documents contained in a Decision Support Package would include:

1. Business Case
2. Risk Analysis (appropriate to the phase being completed)
3. Resource Analysis (appropriate to the phase being completed)
4. Work Breakdown Structure (WBS) also appropriate to the phase being completed
5. Cost Estimate (within acceptable ranges appropriate to the phase being completed)
6. CPM Schedule
7. Supporting technical documentation (i.e. process flow charts or diagrams, major equipment packages required, throughput or output calculations) Eventually this will include detailed design and contract documents for work being outsourced

In all cases the level of detail for all of these packages of documents becomes increasingly more refined as the scope of the project becomes progressively elaborated.  To get a good idea of what information is contained in a Decision Support Package.

01.1.2.1.12 - The Go / No Go Decision

Figure 1 Item 12:- This is normally a business decision made by a team or a group of senior managers, often called a “steering committee” based on the cost estimate, the risks and the business conditions whether to proceed, modify or kill a project.  

These are the people (normally asset or operations managers in their roles as “project sponsors”) who make the strategic decision as to what the right “mix” of projects should be included in their project portfolios.

Figure 5 - The Go / No Go Decision

Source: Guild of Project Controls

01.1.2.1.13 - The Phases of Asset and Project Life Span / Life Cycle

Figure 1 Items #13 through #19:- are typical Phases of an ASSET life span, from conception through disposal. As can be seen from the illustration, the first two phases we do not have a project. All we have are options, some of which may turn into projects, others may not. Research indicates that the while the terminology varies from company to company and from sector to sector, the concept of a phased approach to project development is well established.

Figure 6 - Alternate Names for the Phase Gates

Source: Van der Weijde, Gerard Albert, 2008 "Front-End Loading in the Oil and Gas Industry"

Because of the confusion caused by lack of standardization, and recognizing that the “phase gate approach” to project development represents a “best tested and proven” practice to improve the success rate of projects, the Guild of Project Controls has offered STANDARDIZED terminology as follows:

Figure 7 - Guild of Project Controls Phase Gate Naming Standards with Deliverables from each Phase

Source: Guild of Project Controls

Phase 1- Phase 7 represents the life span of any asset acquired or created by a project while Phase 1 through Phase 5 represents the life span of any single project used to acquire, create, update, expand upon, maintain and eventually dispose of an asset.  To be consistent, the CORE DELIVERABLES from each phase which are to be included in the DECISION SUPPORT PACKAGE (DSP) are also named after the phase they are associated with.  Explained another way at the Phase 1 “go/no go” decision the Decision Support Package (DSP) should contain at MINIMUM:

• Level 1 WBS
• Level 1 Schedule
• Level 1 Cost Estimate.

It would also be expected that a risk assessment using the Level 1 WBS as input would also be a part of the Decision Support Package. For more see Module 4 - Managing Risk.

The concept for using a phase gated approach is that the scope, time and cost will be progressively elaborated becoming less vague and more firmly defined over time. However, as evidenced by the fact that so many projects run late and over budget is an indication that this process is broken or required improvement.

Research has shown that if owners would take more time and do a better job of scope definition AND/OR used the contracting type appropriate to the scope definition they actually produce (see Module 05 - Managing Contracts) that they would have fewer change orders and claims plus their projects would likely finish on time and within budget.

To avoid duplication, the 10,000 Meter Level will only be presented in this module, except where itt has a specific bearing on the inputs, tools, techniques or outputs of subsequent modules.

01.1.2.2 - THE "1,000 METRE" Process Map Defined and Explained

Figure 8 - The 1,000 Metre Level Process Flow Chart for Module 1- Managing Project Controls from both the OWNER and CONTRACTOR ORGANIZATION PERSPECTIVE

Source: Guild of Project Controls

At the 1,000 meter level of detail this is what the process flow chart looks like to manage project controls. As this process applies equally to both the Owner and Contractor organizations, at this level of detail, the process maps are identical.  As the level of detail becomes more granular, we will begin to see many important differences in perspectives between Owner’s project control practitioners and those of Contractors, in terms of both the tactical and strategic objectives of the project.  This includes significant differences in the time horizons as Owner’s project control teams are looking at the Asset life span with the Project life span being just part of a much larger process, while Contractor’s are focused almost entirely on the project life span.

This is the level of detail where, in Module 1- Managing Project Controls, we look at the governance issues such as what type of project management office (PMO), project support services office (PSSO) or project controls office (PCO) is appropriate for our organization and whether creating either functionally organized (i.e. separate planning/scheduling, cost estimating/budgeting and forensic claims) departments or cross functionally organized (project controls). This sets the stage for Module 02, where we define how many people we need to staff our project controls department, what are the hiring criteria and how many of each competency level are we going to need.

This is also where we set up the Double Loop Learning Process, develop the Master template for the Standard Operating Procedures (SoP) and any other processes which apply to or are common to all the modules.

As a GOVERNANCE document, there are no outputs from the Managing Project Controls Module, which is why there are no input lines, however there are feedback lines as applying the Double Loop Learning Process, any of the subsequent 11 Modules can and will serve to continuously improve the processes associated with managing Project Controls. 

01.1.2.2.01 - The Building Block Approach

Because projects vary in size and complexity and because this document is designed to meet the needs of both Owner and Contractor practitioners a "Modular" or "Building Block Approach" was developed which enables organizations / practitioners to organize the basic process building blocks in whatever configuration they deem to be most appropriate to suit their needs, recognizing and accepting that not all blocks of processes will be used on all projects and the sequence of these process blocks may also change.  Thus far, the only organization that has taken the “building block” approach in providing both scalability and flexibility is the Lean Construction Institute.  

Below is a simply process-flow chart:

Figure 9 - Typical Process Flow Chart Approach 

Source: Guild of Project Controls

01.1.2.2.02 - Continuous Process Improvement / Lessons Learned

Because so much of Project Controls is process based, the Guild of Project Controls supports the concept of "Continuous Process Improvement" and have adopted a “Double Loop Learning”¹ model as being the most appropriate tool or technique to ensure that not only are we learning from our mistakes on an individual basis (i.e. “Single Loop Learning”) but that the organizations which employ us our use our services benefit as well.

We can see by the graphic below how we can or should be applying Double Loop Learning as the basis for continuous process improvement to the Project Controls process steps:

Figure 10 - Double Loop Learning

Source: Bryant, Andrew (2010) "Reflecting and Learning: 2009 to 2010"

Applying the Double Loop Learning concept to the typical process flow chart we can see we how this approach results not only in short term solutions to immediate problems or opportunities, but by continuously challenging, testing and validating the assumptions, processes and procedures we are able to build into the system a continuous feedback loop based on “Lessons Learned”.

As capturing and using lessons learned has been and continues to be a major challenge, the Guild of Project Controls is taking an innovative approach to that used by other project management organizations.

Figure 11 - Double Loop Learning Mapped to the GPC Modules Process Flow

Source: Bryant, Andrew (2010) "Reflecting and Learning: 2009 to 2010"

01.1.2.2.03 - Project Management Process Mapped to Guild Modules

Based on an analysis of the dictionary definitions, as well as the research from Cranfield, PMI and the US Government Accountability Office’s “Best Practices in Capital Budgeting” (Chapter 6 Figure 9 on page 51 and Table 5 on pages 54 – 55) we can identify "12 building blocks” which need to be mastered if one is consider themselves a "Project Controls professional” as well as the 12 processes which need to be incorporated into and managed by a Project Controls department.

It is important to remember is that the LEVEL OF DETAIL evolves as the project becomes progressively more elaborated. Drilling down to the project level, we can see that the scope of work defined as “Project Controls” can be further broken down and those 12 blocks of processes can apply at ANY Phase of the project development life span.

These modules have been sequenced based on the processes flow chart followed on “most projects, most of the time”.  Explained another way, lacking any guidance or direction, if a Project Control practitioner was to follow this sequence, he or she probably would be “safe”.  

• The whole purpose in taking a building block approach is recognizing that these processes are not only iterative in many cases but that the sequence they are done in can and will change, depending on whether you are a contractor or owner or if your project needs require that a different sequence be followed.

While all of these modules are “core” to the practice of Project Controls, not all of them are core to the other tracks (Planning & Scheduling, Cost Management and Forensic Analysis).

Note - from a Project Controls perspective, we do not physically EXECUTE the work (refer graphic below).  Our responsibilities come under the INITIATING, PLANNING, CONTROLLING and CLOSING operations.

Figure 12 - Guild Process Modules Mapped to the 5 Project Management Process Groups (Applies at the 10,000, 1.000, 100 and 0 Meter or Ground Level)

Source: Guild of Project Controls

In this model:

• The Initiating / Planning processes are a joint responsibility between the Asset or Operations (program) manager in their roles as project sponsors, and the Project manager, for and on behalf of the Project Control department OR the Project Control Manager, in the event the project controls department is not reporting to the project manager.
• The Executing / Closing processes are the responsibility of those individuals or organizations who are actually doing the work. (i.e. Owner, Contractor, Sub-Contractors, Vendors)

These lines shown in the graphic are approximations only but do give some general sense of the relative level of effort and the typical timing and this defines the roles and responsibilities of the Project Control team once the project has been approved for execution and been funded.

Figure 13 - How the PROCESS GROUPINGS map against the ASSET and PROJECT LIFE SPAN PHASES

Source: Giammalvo, Paul D (2015) Course Materials. Contributed Under Creative Commons License BY v 4.0

In Figure 13 above, we can see that the Figure 4 PROCESS GROUPINGS (i.e. Initiate, Plan, Execute, Control and Close) apply at ALL the PHASES of both the Asset and Project Life Span.

Because Project Control practitioners can play two roles - as Subject Matter Experts (Phases 1, 2, 6 and 7) OR as Key Project Team Members (Phases 3, 4 and 5) our roles and responsibilities will change and will be defined by the needs of the project sponsors and/or project managers, depending upon the phase we are in.  Regardless of which phase we are in, the primary deliverables that we are responsible to produce are data and the associated analysis and projections to enable that Phase to progress. 

Applying this process based model, Project Controls does NOT execute the actual work of the project - that is the responsibility of other members of the project team, including contractors, subcontractors and vendors as well as the owner’s team members (if applicable on your project). Within each Phase, our only obligations as Project Controls practitioners are to EXECUTE those responsibilities to PLAN, CONTROL and CLOSE those work packages or tasks which are directly assigned to us via our schedules.

01.1.2.3 - THE "100 METRE" Process Map Defined and Explained

Many of the tools, techniques and processes use by Project Controls practitioners have been adopted or adapted for use in project management come to us from the early research people such as Henry Fayol, Frederick W. Taylor, Henry Gantt, and the husband-wife team of Frank and Lillian Gilbreth. However, these early 20th Century researchers were not focusing on project management but on operations management.

Thus many of the tools, techniques, methods and practices which have become the basis for “project controls“ are roughly analogous to what is known in the world of manufacturing as “Manufacturing Resource Planning” (MRP) or “Enterprise Resource Planning” (ERP) the only major exception being projects have a finite life, while operations are on-going. Otherwise, both sets of processes utilize many of the same tools and techniques and are expected to fulfill the same purpose, which is to provide asset, operations (program) and project management with the information necessary to make informed decisions in a timely manner.

Our Business Dictionary definition of “Manufacturing Resource Planning” (MRP-II) is a

• “Successor to the material requirements planning (MRP), it integrates planning of all aspects (not just production) of a manufacturing firm. MRP-II includes functions such as business planning, production planning and scheduling, capacity requirement planning, job costing, financial management and forecasting, order processing, shop floor control, time and attendance, performance measurement, and sales and operations planning.”

And the Business Dictionary definition for “Enterprise Resource Planning” is an

• “Accounting oriented, relational database based, multi-module but integrated, software system for identifying and planning the resource needs of an enterprise. ERP provides one user-interface for the entire organization to manage product planning, materials and parts purchasing, inventory control, distribution and logistics, production scheduling, capacity utilization, order tracking, as well as planning for finance and human resources. It is an extension of the manufacturing resource planning (MRP-II). Also called enterprise requirement planning.

Lastly, the definition of “Optimized Production Technology” (OPT) is another term which has significant relevance to the practice of project controls. Optimized Production Technology is defined to be:

• “Production scheduling and inventory control system that (unlike manufacturing resource planning) recognizes bottlenecks (capacity constraints) and does not aim at full capacity utilization at all times. OPT's objective is to simultaneously raise throughput while reducing inventory and operating costs, and achieve a smooth, continuous flow of work in process.

These three definitions provide the conceptual foundation for what we know today at least in construction as “Project Controls”, understanding that these same functions are also known, especially in the world of IT and many government agencies as “project management offices” or “PMO’s”.  Many, if not most of these same functions are also done by other practitioners going under the name of “Cost Engineer”, “Systems Engineer” and “Financial Analysts”.

This module is not about managing the actual projects but about applying the tools, techniques and methodologies we advocate as “best tested and proven” practice to manage the work packages that we are responsible for as project control practitioners. Explained another way, this is where we get to “walk our talk” and “lead by example”.

Figure 14 - Managing Project Controls Process Map 100 Meter Level of Detail

Source: Guild of Project Controls

In this module, we follow the same process and procedure, use the same tools, techniques and methodologies we apply to the projects but now we are applying them to managing our own work responsibilities as project control practitioners.

Explained another way, this module is a microcosm which contains the same methods we are advocating others use, but instead of being applied externally to our clients and other stakeholders, we are applying them to our own internal operations.

This is important for us not only to develop our credibility (“walk our talk”) but it provides us with the opportunity to experiment with continuous process improvement, by applying the double loop learning concept to our project control processes.

01.1.2.4 - THE "0 METRE", "GROUND LEVEL" or "WORKING LEVEL" Process Map Defined and Explained

01.1.2.4.01 - Module 01 - Managing Project Controls

This module is where the governance and organizational structure of a Project Control department or team are developed and implemented.

It covers what skills sets are necessary for each member of the project control team and it explores what forms of “project control” or “project management office” (PMO) are “right” for your business.

This module is where we apply the basic concept of project controls not only to the projects we are responsible for, but also in initiating, planning, executing, controlling and closing our own work packages and activities.

This module consists of 6 sub-modules or sub-processes:

• Module 01-1 - Introduction to Managing Project Controls
• Module 01-2 - Developing a Project Controls Policies and Procedures Manual
• Module 01-3 - Developing the Project Controls Plan
• Module 01-4 - Executing the Project Controls Plan
• Module 01-5 - Controlling the Project Controls Plan
• Module 01-6 - Closing the Project Controls Plan

The key points from this module are:

• Project controls is the facilitator and scribe, capturing the project control plan of the people doing the work, then tracking and reporting actual progress against their plan. Project controls is not or should not be responsible to create the project plan, project controls does not own the project plan. All Project Controls does or should do is to help facilitate project teams to turn what they want to do into a schedule, and to cost and resource load that schedule based on the available resources and then to baseline that schedule when the stakeholders have accepted it.
• Once accepted and baselined, the Project Controls team tracks actual progress against the plan created by those who are going to be executing the work, analyze that progress and report progress to the appropriate decision makers. Ideally, the Project Control team, consisting of subject matter experts in planning / scheduling, cost management and claims, provides stakeholders with options to either keep the project progress on track or if it gets off track, what options does management have to get it back on track. (i.e. “what if” analysis)
• The Project Controls team, consistent with the “double loop learning” model are responsible to update and maintain the cost and schedule (duration and productivity) databases and to settle or otherwise resolve all claims or disputes.
• During the evolution of a project, the Project Control practitioner is likely to play the role of subject matter expert and facilitator. However, once a project has been funded and received the “Notice to Proceed” (NTP) that is when our jobs really start.

01.1.2.4.02 - Module 02 - Managing People

In this module, we have all the training and competency development tools & techniques necessary to create and maintain a functioning Project Controls Department or Project Management Office. (PMO).

In this module, we also identify our stakeholders and determine the criteria against which we will determine the “success” of the project.

This module covers the “soft" or people side of project controls and consists of 5 sub-modules or sub-processes:

• Module 02-1 - Introduction to Managing People
• Module 02-2 - Developing Project Controls Career Path Development Plan
• Module 02-3 - Developing Individual Competencies
• Module 02-4 - Developing Management Competencies
• Module 02-5 - Identifying and Engaging Stakeholders

In this module, we are introducing the fundamental tools, techniques and methodologies most often associated with the practice of project management and those support staff who are part of the project management team.

The key points from this module are:

• You cannot have a successful project management or project control team unless you have the organizational infrastructure in place to support them.
• If you want to increase the probability of “success” from your projects you need to identify who the stakeholders are, what their needs, wants and expectations are and how you can meet them, and if you cannot meet them, then to be able to negotiate the trade-offs necessary to achieve more realistic expectations.

01.1.2.4.03 - Module 03 - Managing Scope

Given we know that poorly defined or missing scope is one of the root causes of cost and schedule over-runs, disputes and claims, this is one of the first responsibilities, whether you are a planner / scheduler or cost estimator.

 

 

This module consists of 6 sub-modules or sub-processes:

• Module 03-1 - Introduction to Managing Scope
• Module 03-2- Developing the Scope Management Policies and Procedures Manual
• Module 03-3 - Validate Stakeholder Expectations
• Module 03-4 - Creating the Work Breakdown Structure
• Module 03-5 - Creating the Control Accounts
• Module 03-6 - Accepting Completed Deliverables

The key points of this module are:

• The importance of adopting standardized wbs structures
• The importance for owners to go to a minimum level 3 and preferably level 4 WBS development
• The process for accepting deliverables promptly and paying for them within a reasonable time after acceptance

01.1.2.4.04 - Module 04 - Managing Risk & Opportunity

All the research indicates that managing risks and opportunities is a weakness in business in general and in project management in particular.

And the reason Managing Risk has been sequenced immediately after Module 03 - Managing Scope is because as scope definition should define exactly 100% of the project at any given point in time, that using the WBS as one of the primary inputs into the risk and opportunity process makes sense.  Putting the risk analysis early on in the process also helps to ensure that when we do our time and costs, that by knowing in advance what the risks are, we can build in appropriate contingency or activities to mitigate or eliminate the risks while maximizing the opportunity.

This module consists of 6 sub-modules or sub-processes:

• Module 04-1 - Introduction to Manging Risk & Opportunity
• Module 04-2 - Developing Risk & Opportunity Management Policies and Procedures Manual
• Module 04-3 - Identify Risks and Opportunities
• Module 04-4 - Assess, Categorize, Prioritize and Quantify Risks or Opportunities
• Module 04-5 - Developing Risk & Opportunity Response Strategies and Tactics
• Module 04-6 - Risk & Opportunity Monitoring and Control

This module is CORE to Planning & Scheduling (PS), Cost Management (CM) and Project Controls (PC) but is SUPPLEMENTAL or SUPPORTING to Forensic Analysis.

The important points from this module are:

• As humans, we tend to be overly optimistic and need to be more conservative and realistic in our time and cost estimates in particular.
• As project control professionals, we have an ethical if not a legal obligation to document our cost and duration estimates and formally object if the client or management over-rides our professional judgment.

01.1.2.4.05 - Module 05 - Managing Contracts

This module was sequenced next because one of the more common risk strategies is to TRANSFER risk, which is normally done via a contractual relationship with one or more parties, known as “Contractors” or “Vendors”. 

What this means is one of the first steps you would take after determining that the risk strategy was to TRANSFER risks, you would have to determine what the appropriate contract is given the scope definition.

This module consists of 6 sub-modules or sub-processes:

• Module 05-1 - Introduction to Managing Contracts
• Module 05-2 - Developing Contracting Policies and Procedures Manual
• Module 05-3 - Select Project Delivery Method/Contract Type
• Module 05-4 - Tendering & Bidding the Project
• Module 05-5 - Managing the Contract
• Module 05-6 - Closing the Contract

The important points from this module are:

• There is a correlation between scope definition, risk apportionment and contract type and to try to use a contract type which is inappropriate to the level of scope definition is almost guaranteed to result in claims, disputes unhappy stakeholders.
• Given that for most owners, the true or real scope definition at the time of contract award averages between 65%-75%, it means the most appropriate contracts for most owners to use would some form of either cost plus with incentives or fixed price with incentives. This is substantiated in aia’s integrated project delivery approach.

01.1.2.4.06 - Module 06 - Managing Resource Acquisition / Allocation

This module follows Module 4- Managing Risk & Opportunity and Module 5- Managing Contracts because this is the second alternative for an owner if they choose NOT to transfer the risk through contracting or outsourcing. Which means for work kept in house, the owner will have to assume the responsibility for acquiring, assigning and managing their own resources.

This is a common practice as we often see Owner Supplied Materials or Owner Supplied Equipment, not to mention the owner’s project manager, project controls team, QA/QC, Safety and security personnel assigned to a project.

Another reason this was sequenced after contracts is for work being outsourced, it will be the contractor or vendors responsibility to source, select, train and manage their project workforce as well as obtain the material and equipment resources necessary to deliver what is required in the contract documents. So while this was sequenced after Module 05 - Managing Contracts, in fact it is more than likely the two will be happening simultaneously or concurrently.

This module consists of 6 sub-modules or sub-processes:

• Module 06-1 - Introduction to Managing Resource Acquisition / Allocation
• Module 06-2 - Develop the Resource Policies and Procedures Manual
• Module 06-3 - Acquiring Manpower for the Project
• Module 06-4 - Acquiring Materials for the Project
• Module 06-5 - Acquiring Equipment for the Project
• Module 06-6 - Allocating Resources

This module is (or should be) CORE to Planning & Scheduling (PS), Cost Management (CM), Forensic Analysis (FA) and Project Controls (PC)

The key points from this module are:

• Construction need dates drive the start of the procurement processes (on the backwards pass) for all resources- manpower, materials and equipment.
• Schedules need to be fully integrated with owner, contractor, sub-contractor and vendor material and equipment procurement.

01.1.2.4.07 - Module 07 - Managing Planning & Scheduling

This module follows next because unless you have the scope of work (WBS), know the risks, know what is required by the contract (either as an owner or contractor) and know what resources are available and what their productivity is, creating a realistic dynamic schedule becomes more an act of faith than it does the application of professional judgment.

 

This module consists of 11 sub-modules or sub-processes:

• Module 07-1 - Introduction to Managing Planning & Scheduling
• Module 07-2 - Develop the Planning & Scheduling Policies & Procedures Manual
• Module 07-3 - Identify / Capture All Schedule Activities
• Module 07-4 - Create The Logical Relationships & Sequencing Activities
• Module 07-5 - Assigning Resources To All Activities
• Module 07-6 - Calculate The Duration Of Each Activity
• Module 07-7 - Calculating Float and the Critical Path
• Module 07-8 - Validate The Critical Path & Completion Dates
• Module 07-9 - Validate Horizontal And Vertical Integration
• Module 07-10 - Conducting A Schedule Risk Analysis
• Module 07-11 - Baselining & Communicating The Schedule

The important points from this module are:

• The schedule is not or should not be created by the scheduler; it is not owned by the scheduler. The scheduler’s role is to facilitate those who are going to be doing the work to explain how they are going to do the work while the scheduler captures their work flow into the schedule. Then once done, the scheduler tracks the actual progress against their plan and provides expert suggestion as to how to keep the work flow going according to the plan.
• The schedule lies at the heart of project controls. It is the single point where the outputs from all other modules comes together in a single document- the schedule.

Figure 15 - Showing the Relationship between the Schedule and other Modules

Source: Adapted from Project Manager’s Desk Reference, 2nd Edition, Lewis

01.1.2.4.08 - Module 08 - Managing Cost Estimating & Budgeting

This module comes AFTER Module 07 - Managing Planning & Scheduling because the timing of activities has a major bearing on the cost of those activities.

As an example, the costs of placing a cubic meter of concrete in Alaska during the winter is three times as costly as placing that same cubic meter of concrete in the summer months. Just as a reminder, while these processes are being shown as being sequential, this is an over simplification to help the novice project control professional gain some sense of the logical flow of work.

In reality, these processes are iterative and happen concurrently. In many cases, the sequence shown here will change, which is why we are using the “building block” approach.

This module consists of 10 sub-modules or sub-processes:

• Module 08-1 - Introduction to Managing Cost Estimating & Budgeting
• Module 08-2 - Developing Cost Estimating and Budgeting Policies and Procedures Manual
• Module 08-3 - Define The Estimates Purpose And Scope Of Work (Owner)
• Module 08-4 - Creating The Owners Cost Estimate (Top Down)
• Module 08-5 - Define The Estimates Purpose & Interpret The Scope Of Work (Contractor)
• Module 08-6 - Developing The Contractors Cost Estimate (Bottom Up)
• Module 08-7 - Validate The Time & Cost Trade-Offs
• Module 08-8 - Validating Horizontal And Vertical Integration
• Module 08-9 - Conducting A Cost Risk Analysis
• Module 08-10 - Baselining And Communicating The Cost Estimate/Cost Budget

This module is (or should be) CORE to Cost Management (CM), Forensic Analysis (FA) and Project Controls (PC) but is SUPPLEMENTAL or SUPPORTING to Planning & Scheduling (PS).

The key points from this module are:

• Cost and schedule are strongly correlated and the combined data results in a “bathtub” shaped curve.
• There is an optimum time-cost trade-off in any project and the project control professional is or should be ethically bound to calculate it and present it to the key decision makers to guide them in the decision making process.

Figure 16 - Showing the NORMAL and OPTIMISED Cost vs. Time Trade offs

Source: US Federal Highway Administration (2011) "Work Zone Road User Costs Concepts & Applications")

01.1.2.4.09 - Module 09 - Managing Project Progress

In this module, there are some 26 different tools/techniques we can apply to measure physical progress as well as some very old fashioned as well as very modern ways to capture physical progress, document it and get it back to the office within a reasonably time frame so that management can apply their knowledge and understanding of what is happening in the field to make decisions in as close to real time as possible.

This module consists of 5 sub-modules or sub-process:

• Module 09-1 - Introduction to Managing Project Progress
• Module 09-2 - Developing Progress Measurement policies and procedures manual
• Module 09-3 - Capturing Progress & Updating the Schedule
• Module 09-4 - Assessing and Interpreting Progress Data
• Module 09-5 - Project Performance Forecasting

The key points from this module are:

• The physical progress on the project has been accurately measured, reported, analysed & interpreted and in as near to “real time” as is humanly possible.

Figure 17 - What the S-Curve Tells Us about Time and Costs

Source: DAU Gold Card (2015)

Figure 18 - What the S-Curve tells us about RESOURCE FLOAT and TIME FLOAT

Source: Adapted from Humphrey's Gary (2015) Project Management Using Earned Value, 3rd Edition

01.1.2.4.10 - Module 10 - Managing Project Change

This module represents what is or should be an on-going process starting from the very inception of the project from the owner’s perspective and not be treated as only an issue between owner and contractor.

As soon as a change of any type is identified, it needs to be analyzed and evaluated for both cost and time impacts. This is especially important for owners to manage their internal changes as aggressively as they manage the change requests put forward by contractors.

This module consists of 5 sub-modules or sub-processes:

• Module 10-1 - Introduction to Managing Project Change
• Module 10-2 - Developing Managing Change Policies and Procedures Manual
• Module 10-3 - Managing Change - The Owners Perspective
• Module 10-4 - Managing Change - The Contractors Perspective
• Module 10-5 - Configuration Management

The key points from this module are:

• Change management is just as important for owners to manage internally as it is for owners to manage change between or with their contractors and vendors.
• If owners were more aggressive about managing changes internally, it would help minimize claims and disputes with contractors after the project has begun.

01.1.2.4.11 - Module 11 - Managing Project Databases

This module represents what is or should be an on-going process. As soon as new data is captured, it needs to be analysed, evaluated and archived for use immediately.

For a contractor in particular, this becomes important because you are using today’s productivity and cost information as the basis to bid tomorrow’s work, meaning that maintaining an accurate and up to date database is essential to your survival.

This module consists of 4 sub-modules or sub-processes:

• Module 11-1 - Introduction to Managing Project Databases
• Module 11-2 - Designing the Project Database
• Module 11-3 - Creating the Project Database
• Module 11-4 - Updating and Using the Project Database

The key points from this module are:

• Both cost and schedule (productivity) databases are important to both owners and contractor’s but generally more important to contractors.
• To be the most value, standardized coding structures enable benchmarking with other companies or other countries.

01.1.2.4.12 - Module 12 - Managing Forensic Analysis

This module covers the post project processes of analysing, calculating and assessing damages, negotiating or otherwise resolving claims or disputes through increasingly more time consuming and costly means.

 

 

This module consists of 7 sub-modules or sub-processes:

• Module 12-1 - Introduction to Managing Forensic Analysis
• Module 12-2 - Creating the Forensic Analysis Process and Procedures Manual
• Module 12-3 - Conduct the Preliminary Analysis
• Module 12-4 - Conduct the Schedule Analysis
• Module 12-5 - Damage Analysis Phase
• Module 12-6 - Settlement Negotiations Phase
• Module 12-7 - Formal Disputes Resolution

The key points from this module are:

• While it is far better to try to avoid claims and disputes, given they are an unfortunate reality in today’s world, we need to be proactive in identifying them as quickly as possible, and resolving them as quickly as possible otherwise we risk souring the relationship between owner, contractors and subcontractors.

01.1.3 - BACKGROUND INFORMATION FOR MANAGING PROJECT CONTROLS

01.1.3.1 - PROJECT CONTROLS ORGANISATION STRUCTURES

As we know from Module 02 - Managing People, unfortunately, there is little agreement on exactly what a Project Control Office is, much less what it does. The graphic below was taken from research done at Cranfield University and represents what the Guild of Project Controls believes to be the most current and comprehensive explanation.  In the Cranfield model, they identified two drivers- Demand which is focused on what the market needs or wants (the PRODUCT of the project) vs the Supply side, which focuses more on just the project itself.

Figure 19 - Four generic models of Project Control or Project Management Offices PMO’s

Source: Cranfield University (n.d.) PMO- Project Management Offices

Additional definitions come to us from PMI in their November 2013 “Pulse of the Profession”² research, which identified 5 different types of Project Management Office (PMO’s):

01.1.3.1.01 - The Project Specific PMO / Project or Program Office (PO)

TYPE (1) - The Project Office (PO) provides a range of project or program support services as a temporary entity established to support a specific project or program. These services may include supporting data management, coordination of governance and reporting, and administrative activities to support the project or program team. The project office may coordinate with other PMO entities to support organizational governance requirements, to provide project or program artifacts, and to facilitate knowledge management activities. The project office typically does not exist beyond the lifespan of the project or program it supports.

01.1.3.1.02 - The Project Support Office / Services or Controls Office (PSO)

TYPE (2) - The Project Support Office (PSO) provides enabling processes to support the management of project, program or portfolio work. It utilizes the governance, processes, practices, and tools established by the organization and provides administrative support for the delivery of the project, program or portfolio work within its domain. When appropriate, it may also develop tools and practices to specifically support a particular project effort. Additionally, it may support mentoring, training, and certification activities for project managers within its area of responsibility.

01.1.3.1.03 - The Enterprise, Corporate, Global PMO (EPO)

TYPE (3) - The Enterprise Project Office (EPO) is the highest-level PMO entity in an organization, often responsible for alignment of project and program work to corporate strategy; establishing and ensuring appropriate enterprise project, program, and portfolio governance; performing portfolio management functions to ensure strategy alignment and benefits realization; and related functions responsible for alignment of initiatives to corporate strategy. The Enterprise PMO may facilitate governance at the enterprise level and may incorporate strategy development and strategic planning support. The Enterprise PMO may have direct responsibility for or influence over other lower-level PMOs. Management of multiple stakeholders and ensuring continuous communication are important roles of the enterprise PMO.

01.1.3.1.04 - The Organizational, Business, Divisional or Departmental Unit (PMO)

TYPE (4) - The Project Management Office (PMO) supports the organizational unit strategy by providing PMO services—including, but not limited to, portfolio management, governance, and operational project support— to a specific organizational unit. This PMO may also provide appropriate information to other PMO entities as part of organizational governance and may be responsible for the consolidated reporting for the projects, programs, and portfolios within its domain.

01.1.3.1.05 - Center of Excellence / Center of Competency

The Center of Excellence...

• Supports the execution of project work by equipping the organization with methodology, standards and tools to enable managers to better deliver projects.
• Increases the capability of the organization by implementing good practices and providing a central point of contact for managers.
• May provide training, mentoring and capability development for people and could also facilitate knowledge management through knowledge capture and information distribution. 

01.1.3.1.06 - The Guild of Project Controls Career Path

The Guild of Project Controls has developed a Career Path which is generally accepted as being typical of the career paths followed by many employers and practitioners.

Figure 20 - Guild of Project Controls Career Path

Source: Guild of Project Controls

As we can see, there are a multitude of approaches a person interested in the “project controls” can take:

1. The first is we can become SPECIALISTS in a specific track or stream, meaning we can progress vertically specializing in one specific area, i.e: Planning and Scheduling (PS), Cost Management (CM) or Forensic Analysis (FA)
2. The second is to become a more GENERALIST or more ROUNDED approach by becoming Certified in Project Controls and to do this you would need to earn all three certifications at a given level in order to be certified at that level as a Project Controls Professional.  Explained another way, if you were to earn the Practitioner level for the PS, CM and FA track, then you would automatically qualify for the Practitioner level as a Project Controls Professional.

For more information check out Module 02-2 - Develop Project Controls Career Path Development Plan and / or the Guild of Project Controls Certification Career Path(s).

01.1.3.1.07 - The Recommended Project Controls Organization Structure

Figure 21 - The Ideal Project Controls Organization Structure

Source: Guild of Project Controls

It can be said that Project Controls departments:

• Provide professional services in support of projects by helping them create realistic, achievable project plans and budgets, and
• Serve as an independent auditing function to track and report progress against the project manager’s plan,

Because of these two roles it is not advisable to have the project control team report to the project manager. There are too many instances where the project manager has directed the Project Control practitioner to change or modify progress or cost data to hide “bad news”.

For this reason, the ideal or recommended Project Control organization structure has a Director of Project Controls / Director of Project Management Offices (PMO) which is equal to if not higher than that of a project manager.  It is this Director of Project Controls to whom all the Project Controls practitioners report.

Using this model, during the planning phases of a project the appropriate project controls professional (PS, CM, FA or CM) are assigned to the project manager in a SUPPORTING role, and then when the project plan has been accepted and baselined, then the Project Controls department provides:

• Independent auditing, monitoring and validating progress against the plan, but also providing
• Professional advice or suggestions on how to prevent the project from falling behind schedule and / or running over budget, and if it does, what ideas or suggestions might help to get it back on schedule and/or within budget.

For more on managing using a Matrix organization structure, refer to Module 02- Managing People.

01.2 - Module 01-2 - Developing The Project Controls Policies & Procedures Manual

01.3 - Module 01-3 - Developing The Project Controls Plan

01.4 - Module 01-4 - Executing The Project Controls Plan

01.5 - Module 01-5 - Controlling The Project Controls Plan

01.6 - Module 01-6 - Closing The Project Controls Plan

GPCCAR M01-1 Managing Project Controls, Introduction, Revision 1.07

Revision History:

• Rev 1.01 to 1.04 – minor narrative improvements
• Rev 1.05 – amended definition of “Project” in section 01.1.2.1.08 - The Project Life Span 
• Rev 1.06 - amended Figure 4, 15 and 22
• Rev 1.07 - renumbered section 01.1.2.2 to have three subsections 01, 02 and 03