60R-

10

DEVELOPI
NGTHEPROJ
ECT
CONTROLSPLAN
 AACE® International Recommended Practice No. 60R-10

DEVELOPING THE PROJECT CONTROLS PLAN

TCM Framework: 8.1 – Project Control Plan Implementation

Rev. December 21, 2011

Note: As AACE International Recommended Practices evolve over time, please refer to web.aacei.org for the latest
revisions.

Any terms found in AACE Recommended Practice 10S-90, Cost Engineering Terminology, supersede terms defined in
other AACE work products, including but not limited to, other recommended practices, the Total Cost Management
Framework, and Skills & Knowledge of Cost Engineering.

Contributors:
Disclaimer: The content provided by the contributors to this recommended practice is their own and does not necessarily
reflect that of their employers, unless otherwise stated.

H. Lance Stephenson, CCC (Primary Contributor) Rob Hartley, PSP

John K. Hollmann, PE CCE CEP Rajasekaran Murugesan, CCE
Michael A. Farin W. James Simons, PSP
Copyright © AACE® International AACE® International Recommended Practices
Single user license only. Copying and networking prohibited.

This document is copyrighted by AACE International and may not be reproduced without permission. Organizations may obtain permission
to reproduce a limited number of copies by entering into a license agreement. For information please contact [email protected]
AACE® International Recommended Practice No. 60R-10
DEVELOPING THE PROJECT CONTROLS PLAN
TCM Framework: 8.1 – Project Control Plan Implementation

December 12, 2011

TABLE OF CONTENTS

Table of Contents ..........................................................................................................................................................1

Introduction ...................................................................................................................................................................1
Purpose ......................................................................................................................................................................1
Background ................................................................................................................................................................2
Using the Project Controls Plan with a Phased Project Process ................................................................................3
Continuous Improvement During the Project Life Cycle ...........................................................................................4
Recommended Practice .................................................................................................................................................4
The Body of the Project Controls Plan ...........................................................................................................................5
Supporting Information for Development and Implementation .................................................................................21
References ...................................................................................................................................................................21
Contributors.................................................................................................................................................................22

INTRODUCTION

This recommended practice is intended to serve as a guideline, not a standard. As a recommended practice of
AACE International, the intent of the guideline is to improve the communication among stakeholders involved with
preparing, evaluating, and using project controls information. This recommended practice (RP) of AACE
International defines the overall development, implementation and management of a project controls plan. This
deliverable can be included as part of an overall project execution plan (PEP) or considered a standalone document
that describes specific approaches that each functional entity will use (engineering, procurement, construction,
safety, quality, etc.).

The project controls plan describes specific processes, procedures, tools and systems that guide and support
effective project control. The plan is a narrative or qualitative representation of the project control process, while
the estimate, budget, schedule, etc. represent the quantitative aspects. Organizations may use this RP to develop
a fit-for-use template as a model document, which is further customized for each specific project.

Purpose

This RP is intended to provide guidelines (i.e., not a standard) for the development of a project control plan that
most practitioners would consider to be good practices that can be relied on and that they would recommend for
use where applicable.

The purpose of the project controls plan should include, in part:

• A plan to implement an integrated set of work processes, procedures and applications to plan, monitor,
execute and control the work. For all intents and purposes, the TCM Framework will provide the basis for
general work processes. Procedures and applications (systems) can be specific to an organization or a
project, and therefore, all procedures and applications to be used should be stated in the project controls
plan.

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 2 of 22

December 12, 2011

• A plan to implement an integrated suite of applications (systems).

• A plan to identify the roles, responsibilities, and accountabilities for the project controls team members.
• A plan to produce the project control deliverables, expectations and scope of work

The use of a project controls plan is considered a leading indicator for assisting in the success of the delivery of the
project. The time invested in preparing, documenting, and communicating a solid project controls plan will
increase the success of the execution of the project. The introduction of the project controls plan and all aspects
within this document assist the project team in reducing project delivery risk. Therefore, any consideration not to
implement the project controls plan in whole or portions of introduces a level of risk to the project.

Background

This recommended practice (RP) describes the important elements of defining the project controls plan and the
requirements for communicating project information to the project team and its stakeholders. This recommended
practice coincides with the TCM Framework.

As part of the TCM Framework, the project controls plan should provide the project team and its stakeholders the
process model based upon the PDCA management or control cycle. As stated in the TCM Framework, the PDCA
model is a generally accepted quality driven, continuous improvement management model.
The project control process is the recursive process cycle nested within the “do” step of the strategic asset
management process cycle. Therefore, the project control plan will only apply to the project control process.

The PDCA steps of the project control process cycle include:

1. Project Planning
2. Project Implementation
3. Project Performance Measurement
4. Project Performance Assessment

Project control is a process for controlling the investment of resources in an asset. The project controls plan is
considered the communication tool for instituting the project control process.

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 3 of 22

December 12, 2011

PLAN
Project Historical Database Management Iterative, concurrent processes
(10.4) ACT DO
Schedule Planning CHECK
Historical Actual Historical Actual and Development
Data Data Data Data (7.2)
Schedule
Strategic Asset Baseline
All Project Control
Management (Activities)
Processes
Process Cost Estimating
(7.1 to 10.3)
(2.3) and Budgeting Cost
(7.3) Baseline
(Budget) Project Control Plan
Project Implementation Basis
(Asset Scope, Project System Implementation
Requirements, Budget, etc.) Resource (8.1)
Change Resource Baseline
(Quantities)
Management Planning
(10.3) Project Scope (7.4)
and Execution Baseline
Scope WBS &
Plans
Change & Strategy Execution
Forecasts Development Strategy Contract
Requirements
(7.1) Procurement
Forecasting
Planning
(10.2)
(7.7) Baseline
Project Cost Plans
Accounting
(9.1)
Analysis Basis & Feedback
Improvement Opportunities
(variance from baseline plans)

Project Progress and

Analysis Value Analysis and
Performance Status Checks Risk Management Performance
& Feedback
Basis & Engineering
Assessment Feedback (7.6) Measurement
(7.5)
(10.1) (9.2)

Cost, Progress and Performance Measures

Figure 1 – Project Controls Process - Total Cost Management Framework

Project control may be considered the quantitative resource control subset of the project management process,
and therefore, the project controls plan should be considered a subset or compliment to the overall project
execution plan. Prior to developing the project controls plan a requirements elicitation and analysis process should
be completed. The requirements elicitation and analysis process will assist the team in identifying the stakeholders
(decision-makers and those who interface with project controls) needs, wants, and expectations; and documenting
them in a form that supports planning, communication, implementation, measurement, and assessment. Figure 1
represents the project controls process of the Total Cost Management Framework.

As identified earlier, the project controls process is an integrated and quality driven process model. Also, the
application of the project controls process provides our membership and others in exercising due diligence in the
stewardship of the six elements of project controls, which are:
• Know what has to be done
• Know what has been done
• Know how actual performance compares with baseline
• Know what remains to be done
• Identify and implement corrective actions to bring performance in line with expectations
• Check results of corrective action

Using the Project Controls Plan with a Phased Project Process

A phased project process, often known as a stage-gate process is a conceptual and operational road map for
moving new projects from proposal to closure. Stage-gate divides the effort into distinct stages separated by
management decision gates (gate keeping). Project teams must successfully complete a prescribed set of related
activities in each stage prior to obtaining management approval to proceed to the next stage of project delivery. In

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 4 of 22

December 12, 2011

its simplest terms, the stages of a phased project process can be:
• Ideation
• Planning
• Execution
• Closure

Specific industries, such as IT, pharmaceuticals, and the process industry have identified the stages that reflect
their business models. In some cases, stages are supported by AACE International Recommended Practice No 17R-
97, Cost Estimate Classification System. A key concept for project control plan implementation is phased control
(continuously involved in all phases of a project), which recognizes that project control must start when work
begins for a project phase. Implementation of project control cannot wait until the start of execution phase.

Continuous Improvement During the Project Life Cycle

It is expected that the project controls plan continuously be updated during the life of the project in order for the
project team and its stakeholders to be kept current of the requirements and expectations of the project controls
team.

The project controls plan is considered a dynamic document, and as such, revisions will be required and be
distributed (revision control is required for the purposes of ensuring that the most current information is
communicated to the project team and stakeholders). The project controls plan recommended practice and the
plans of practitioners using this RP are dynamic and may undergo change based on contemporaneous practice.

RECOMMENDED PRACTICE

The project controls plan is considered the scope of work (SOW) for the project controls team that will support the
overall project team and its stakeholders. To further assist in understanding the requirements of project controls,
the project controls plan is divided into five (5) sections, with each section defining the recommended
requirements for the development of the project controls plan. Section Two describes the major steps or sub-
processes of project controls as per the TCM Framework. The major steps or sub-processes are organized by the
PDCA model, as described earlier. The following can be considered the table of contents of the project controls
plan:
1. Project Control Plan General Requirements
a. Mission Statement
b. Delegation of Authority Guideline
c. Compliance
d. Revision Control
e. Organization for Project Control
i. Organization Chart
ii. Organizational Breakdown Structure (OBS) Development
iii. RACI (Responsible, Accountable, Consulted, and Informed) Charts
iv. Transition Planning
2. Functional Applications of Project Controls (as per TCM Framework)
a. Project Planning
i. Project Scope and Execution Strategy Development
ii. Control Account Development
iii. Schedule and Cost Planning: Iterative and Concurrent Processes
1. Schedule Planning Development

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 5 of 22

December 12, 2011

2. Cost Estimating and Budgeting

3. Resource Planning
4. Procurement Planning
iv. Value Analysis and Engineering
v. Risk Management
b. Project Performance Measurement
i. Project Cost Accounting
ii. Progress and Performance Measurement
c. Project Performance Assessment
i. Project Performance Assessment
ii. Forecasting
iii. Change Management
iv. Project Historical Database Management
3. Systems and Data Integrity Plan
a. Systems
b. Data Integrity and Backup
c. Electronic File Transfer
4. Communications Plan
a. Meeting Requirements
b. Reporting and Frequencies
c. File Structures
5. Project Controls Deliverables
6. Project Controls Plan Implementation
a. Review and Validation
b. Communicating the Project Controls Plan
c. Training
d. Audits

THE BODY OF THE PROJECT CONTROLS PLAN

The following provides the user of this recommended practice with an understanding of the requirements in order
to develop an appropriate plan for a specific project.

1. Project Controls Plan General Requirements

a. Mission Statement

The purpose of the mission statement is to assist in providing the appropriate guidance of the actions
of the project controls organization and project controls team. The mission statement will provide the
framework or context within which the project strategies are formulated (e.g., do we encourage
limited reporting or introduce analysis and recovery strategies? Do we include causal measurement
such as work sampling or only lagging metrics assessment (EV)? Is speed paramount or accounting
perfection? Do we prefer actionable intelligence or data, etc.). The mission statement will provide
justification for the actions that the project controls team will undertake.

b. Delegation of Authority Guideline

The purpose of the project controls plan is to implement an integrated set of work processes,
procedures and applications to plan, monitor, execute and control the work as well as a plan to
produce the project controls deliverables. In order to ensure compliance that the project controls

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 6 of 22

December 12, 2011

plan is being developed and instituted as the official document, a governing body and governance
support needs to be assigned. This governing body may be a subject matter expert, corporate
governance officer, project sponsor, executive director, or even the project manager. In accordance
with the project controls plan, administration and compliance to the document is assigned to the
appropriate authority level.

c. Compliance

Once the project controls plan has been developed and implemented, the project team will be
required to comply with all associated sections of the project controls plan. Compliance of the
requirements of project controls provides the necessary project stewardship and reporting
deliverables so that the project team can maintain the execution of the approved scope of work. A
brief description should be written in the project controls plan identifying the compliance
requirements, responsibilities, and corrective actions.

d. Revision Control

Since the project controls plan is considered a dynamic document (continuously updated during the
life of the project), a management of change policy should be introduced to allow for any editing or
the addition / deletion to the body of the document. Any changes can only be made by re-issuing the
project controls plan with a new, approved revision number. Since this is considered a controlled
document, you may want to use your document control department for the release of project
controls plan. A revision log identifying the revision and a brief description should be available for all
stakeholders of the project. The management of change policy should also determine who approved
the changes, who distributes the changes, and how copies (obsolete or new) will be managed. New
and revised project controls plans should be issued as per the delegation of authority document.

To support revision control, a consolidated list of all supporting documents (i.e. procedures,
processes, roles & responsibilities, estimates, baseline schedule, and key performance indicators,
etc.) should be included as part of the attachments to the project controls plan. The consolidated list
should identify the document name, document ID, revision number, and revision date.
e. Organization for Project Control

The risk or size of the project, or a combination of both, will determine the requirements for the
development and dimensioning of the project controls organization. For smaller projects, the project
control process may be managed by the project leader, or designate. For larger projects, discrete
personnel may be required to carry out functional aspects of the project controls responsibilities,
such as planners/schedulers, cost engineers, estimators, etc.

i. Organization Chart

The design of the project team is dependent on the size of the project, complexity, contract type,
scope of work, required deliverables and level of detail. As part of the project controls plan,
please provide a brief understanding of the project controls resource requirements. The project
controls plan should identify the various key team members and their responsibilities. This
should include the roles and functions of each team member. An organization chart should be
developed and submitted as part of the project controls plan.

ii. Organization Breakdown Structure (OBS)

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 7 of 22

December 12, 2011

Organizational breakdown is focused on translating resource provisions into general approaches

for what work is to be performed, and by whom. Similar to the WBS, organizational
responsibilities can be broken down in a logical, hierarchical manner resulting in an organization
breakdown structure (OBS). Depending on the integration / interface requirements of a project,
the project team may want to assign organizations responsibilities to specific scope elements,
specifically, an OBS / WBS Relationship Chart. The OBS / WBS Relationship chart is a matrix table
that identifies the WBS Elements on the vertical axis (left-hand column) and the organizations
responsible for delivering the WBS elements on the horizontal axis (top row). Organizations may
include the owner, engineering / architectural firms, equipment vendors and constructors.

iii. RACI (Responsible, Accountable, Consulted, and Informed) Charts

Similar to the organizational breakdown structure, the RACI chart is developed to communicate
each party’s or individual’s specific involvement in task and deliverable creation and review. The
RACI chart is a matrix table that identifies the tasks on the vertical axis (left-hand column) and
the roles of the tasks on the horizontal axis (top row). Again, please consider the risk and size of
the project as well as the agreed-to deliverables to ensure that your project has the appropriate
coverage to manage and execute the work. A RACI chart should be developed for each project,
regardless of size or complexity.

iv. Transition Planning

Transition planning is a partnership involving the project controls specialist, their expectations
and deliverables, the project team, stakeholders and other key people involved with the project.
Part of the transition planning is preparing for individuals that leave the project due to
unforeseen circumstances. The project controls plan should indentify the requirements for
replacing project personnel and transitioning new project members in an expeditious effort to
minimize learning curve and possible delays.

2. Functional Applications of Project Controls (as per TCM Framework)

a. Project Planning
i. Project Scope and Execution Strategy Development

The project scope, contract requirements, internal corporate requirements, and execution
strategy provide the project team with the basis for the development of the project controls
plan.

The project scope should be supported by the following documents. Ensure that all documents
and their revision numbers are documented as the “control source” for the project. The
following documents may be included as a separate attachment to the project controls plan:

1. Contract, complete with addenda, omissions and exclusions

2. General and particular conditions
3. Project specifications
4. Scope of work (included and excluded)
5. Work breakdown structure
6. Project control accounts
7. Drawings
8. Bid price (estimate), estimate basis, risk / event log, assumptions
9. Tender schedule, schedule basis, risk / event log, assumptions

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 8 of 22

December 12, 2011

10. Execution plan

The execution strategy should describe and identify three (3) items.

1. Briefly describe the type of work (new project, addition or expansion, revamp,
relocation).
2. Briefly describe the execution strategy, specifically whether the project is considered
one of the following:
a. Standard execution (standard workweek, spot overtime, non-shutdown)
b. An aggressive execution approach (non-standard workweek, high overtime)
c. Fast-track approach (engineering incomplete at the start of construction plus
aggressive execution)
d. Shut-down (planned shut-down, non-standard workweek, high overtime)
3. Briefly describe the contracting strategy.
a. Self-perform, prime contractor, multiple contracts, alliance, joint venture.
When entering into an alliance, joint venture or multiple contract environment, the
project team must consider how coding structures, systems, accounting practices,
etc. will be integrated (or mapped) within the environment.

ii. Control Account Development

A key concept for project control plan implementation is that the control account integrates all
the project control plan components (i.e., cost, schedule, resources, risk, and procurement). The
control account relates directly to a work package component from the work breakdown
structure (WBS) for which responsibility has been assigned (in accordance with the organizational
breakdown structure (OBS) and the procurement plan), and for which cost budgets and
resources have been assigned, and activities scheduled.

At the start of the planning process, the control accounts are developed by the project control
person or team. The following is an example of typical control account characteristics:
• WBS
• OBS
• Work package: scope description
• Responsibility: contractor, discipline, lead person, etc.
• Budget: costs and revenue
• Resources: labor hours, material quantities, etc.
• Schedule: network activities
• Code of accounts: cost category, type or element

iii. Schedule and Cost Planning: Iterative and Concurrent Processes

The following section describes the iterative and concurrent processes that are required to
develop and communicate the integrated performance measurement baseline documents, such
as the estimate, schedule, resource histograms, etc. Therefore, close and iterative integration of
the cost and schedule elements is essential to the development of the performance
measurement baseline in order to ensure the successful execution of the project.

1. Schedule Planning Development

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 9 of 22

December 12, 2011

The project schedule is considered one of the most important aspects for the execution of
the project. Therefore, the development of the project schedule will be given full
consideration, since it (the schedule) sets the baseline measurement for the project. The
project schedule supports the time distribution of resources for activities, which support
earned value management methodologies.

For the development of the schedule to be complete, the planning and scheduling
requirements must be established and integrated with estimate development. This will
include internal (developer / owner) and external (contract) conditions and requirements, as
well as a common WBS, resources, codes, etc.

The project controls plan will address the integration of the schedule development, basis of
schedule and schedule validation process. The plan will identify the level of detail required
for the various schedules that are prepared during the project, including resource loading
and leveling (i.e. the schedule must be detailed enough to show the effect of a changed
condition to an activity sequence as well as to accrue costs associated with scheduled work
activities based on the estimate and/or budget).

2. Cost Estimating and Budgeting

The project controls plan must outline the methodology for establishing the effort to
perform the scope of work and the associated project budget, and to address the integration
of the budgeting process with the schedule to ensure a performance measurement baseline
is properly established.

Like the Schedule Planning Development Section (2.a.1), the project controls plan will
address the integration of the estimate development, basis of estimate and estimate
validation process. The project estimate should be delivered in a standard hierarchy, for
example.

Cost Estimate Hierarchy

• Direct Costs
• Labor
• Material
• Equipment
• Subcontract
• Indirect Cost
• Taxes
• Risk
• Profit
• Contingency
• Overhead
• Escalation

One final thought to consider is for the project team to provide an understanding as to how
revenue (price) versus the cost of the project will be managed and communicated. Based on
contract type (lump sum, cost plus, or unit pricing), clients or other parties may want to
communicate or have communicated the profits (price minus cost) of the project.

3. Resource Planning

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 10 of 22

December 12, 2011

The project team is required to understand how the appropriate resource requirements
were determined to support the execution of the project. The resource management section
may want to specifically outline the requirements for labor resources and site equipment.
For material planning, see Procurement Planning (2.a.4).

Labor Management Planning

Labor management planning is designed to facilitate the collection and reporting of the
project labor (home office, field office, engineering disciplines, and field trades). Time-
phased usage profiles and histograms based on the project schedule and estimate
should be developed as an output for measuring actual hours / costs against the
planned hours / costs to support the evaluation of performance and prediction of final
forecast hours / costs.

Equipment Management Planning

Like labor management, equipment management planning is designed to facilitate the

collection and reporting of the site equipment. Usage profiles will be developed as an
output for measuring actual costs against the planned costs to support the evaluation of
performance and prediction of final forecast costs.

4. Procurement Planning

Procurement planning is the part of the project control planning process that ensures
information about resources (e.g., labor, material, etc.) as required for project control is
identified for, incorporated in, and obtained through the procurement process. The project
controls plan does not explicitly include the procurement process. The project controls plan
only addresses the project control interface with procurement.

Procurement planning is crucial to the success of the project. The project team is required to
determine and communicate the procurement plan, which must include information on both
equipment and bulk purchasing, and subcontracting as identified by the scope of work.
Procurement planning should identify the relationship of the scope of work to the work
breakdown structure (WBS) and organization breakdown structure (OBS).

Equipment and Bulk Purchasing Plan

This section provides the project team with the opportunity to communicate the
requirements on how permanent materials and equipment will be purchased, as well as
delivered. The procurement plan requirements should also indicate on site material
management and logistics for transporting materials. The equipment and bulk
purchasing plan should include for imported goods and services, as well as freight and
logistics considerations. Finally, the plan should identify site material storage and
management requirements.

Contractor Plan

Contractors generally prepare their own control plans and control accounting. However,
these must be consistent with the overall control plans and accounting to the extent
required by the contract. A complete list of contractors and subcontractors should be

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 11 of 22

December 12, 2011

provided. The list should outline their scope of work, start and completion dates, and
the original budget.

iv. Value Analysis and Engineering

The objective of value engineering is to improve the value for the intended asset or project
objectives. Improvement techniques could either be improving the function or reducing the cost
or both. This section of the project controls plan should communicate how value engineering will
be introduced and supported throughout the life of the project, and identify the decisions and
outputs derived from the VA/VE process. The project controls plan does not explicitly include the
value analysis and engineering process. The project controls plan only addresses the project
control interface with VA/VE.
Further to understanding value analysis, also known as value enhancing practices (VEP’s), certain
industries have identified two main categories to recognize and improve the value analysis
process. The two categories are:
• Value Improving Practices (VIPs)
• Project Execution Best Practices

Examples of value improving practices and project execution best practices are:
• Project Functional Objectives
• Energy Optimization
• Technology Selection
• Waste Minimization
• Process Simplification
• Effective Design Tools
• Design to Capacity
• Constructability
• Customized Standards and Specifications
• Value Engineering
• Predictive Maintenance
• Reliability Modeling

v. Risk Management

Risk management is the process of identifying risk factors (risk assessment), analyzing and
quantifying the properties of those factors (risk analysis), mitigating the impact of the factors on
planned asset or project performance and developing a risk management plan (risk mitigation),
and implementing the risk management plan (risk control).

This section of the project controls plan should communicate how risk management will be
introduced and supported throughout the life of the project. The project team should further
describe both qualitative and quantitative aspects of risk.

b. Project Performance Measurement

i. Project Cost Accounting

The project controls plan will address the interface requirements with cost accounting to develop
the methods for the collection of cost commitments and expenditures. The project cost
accountant will support the administration of cost collection, analysis, and forecasting. It is not

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 12 of 22

December 12, 2011

only important to have a cost accounting structure that supports the development of the
estimate and budget; it is equally important for the project team to ensure that all actual values
are coded correctly.

The financial system is usually considered the repository for all cost transactions for the
organization. Other systems may import data from the financial system to support reporting for
control accounts, work breakdown structures, schedule of pay values, etc. The following
identifies other aspects the project team and the accountants need to be aware of:
• Work In Progress (WIP), Accruals
• Cost of Money (Financing)
• Invoicing
• Cash Flow
• Cost vs. Revenue
• Taxation & Depreciation
• Etc.

ii. Progress and Performance Measurement

The progress and performance measurement section identifies the process and methodology
necessary to perform progress and performance measurement and reporting. The progress and
performance measurement process will allow the project team to review the current
performance of the work from inception to completion through periodic updates, and to
facilitate the adjustment of their efforts to meet the changing circumstances.

In order to ensure that proper earned value management is applied and understood, the project
team should describe the methodologies to be used for capturing work accomplished. Different
industries and companies may apply different methodologies when communicating work
accomplished. The following identify the methodologies used in progress measurement.
• Units Completed – This measurement method can be used when work package scope can be
further decomposed into fairly homogenous units of work (e.g., units of material, drawings,
lines of code, function points, etc.) that each require approximately the same level of effort
to produce, and for which work is usually completed, and can be measured, for some units
while work continues on others.
• Incremental Milestone – This measurement method can be used when work package scope
is one deliverable (i.e., not many units as described above) or a set of deliverables done
together, for which multiple activities must be performed in sequence and for which the
completion of incremental tasks can be observed.
• Judgment or Supervisor Opinion - This measurement method is the most subjective and is
used when more objective methods are not reasonable. In this method, the person
responsible for the work package estimates the percent complete based on his or her
informed judgment.
• Resource Expenditure (Level of Effort) or Cost Ratio - This measurement method is generally
used when the work package scope does not include discrete deliverables or milestones and
for which the activities are of long duration and of a relatively constant level of effort. These
most often include management and support labor cost accounts (e.g., project management,
project control, quality assurance, etc.).
• Weighted or Equivalent Units - This measurement method is a hybrid of units completed and
incremental milestones. It is used when the work package scope includes non-homogenous
units of work and/or work tasks that overlap such that the other methods don’t work well.

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 13 of 22

December 12, 2011

c. Project Performance Assessment

i. Project Performance Assessment

The project performance assessment section of the project controls plan identifies the process
and methodology necessary to perform performance assessments and reporting. The use of each
assessment method (e.g., earned value, work sampling, etc.) should be planned in a way that
optimizes the identification of variances, and opportunities and risks for all aspects of the
project. Optimally, the assessment should provide the team with an understanding of work
accomplished. Another aspect is to ensure that the interfaces (i.e., data transfer) between
measurement systems (e.g., payroll systems, material management systems, etc.) and systems
used for assessment (e.g., scheduling software, cost processors) is complete and understood.
Also, the interaction/interface with any owner, supplier, and contractor should support the
reporting systems in order to address the performance measurement and assessment
responsibilities.

After project performance measurement and assessment have been planned, and the
measurement processes and systems have been initiated, the use of assessment methods can
begin. The areas that require assessment are:
• Cost Performance
• Schedule Performance
• Resource Performance
• Work Process & Productivity
• Risk Factors

Once completed, the project team needs to report the assessment that has been completed.
These observations—along with schedule, resource, productivity, and work process and
performance assessments—will be used in the forecasting process.

ii. Forecasting

Forecasting is the process of evaluating project control baselines in consideration of assessments

of ongoing project performance. The forecasting process should be performed in a proactive,
systematic approach based on an established update frequency, rather than being performed in
reaction to performance problems. For the purposes of this section in the project controls plan,
the project team will define the forecasting process to be used to assess each applicable element
of the project, which may include scope, schedule, budget, resources, and risks.

The inputs to the process include plans, performance and progress assessments (which include
project cost accounting, and progress & performance measurement), values analysis, risk
management and change management information. These forecasts should be reported in a way
that highlights performance variances and issues that need project management attention. This
section of the project controls plan should address quantitative forecasting for both cost and
schedule values.

Cost Forecasting

There are three basic forecasting approaches, as identified below.

• Estimate At Completion = Actual Cost + Estimate To Complete
• Estimate At Completion = Actual Cost + Budget At Completion – Earned Value

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 14 of 22

December 12, 2011

• Estimate At Completion = Budget At Completion ÷ Cost Performance Index

The project team must determine the best possible solution that identifies an accurate EAC, and
supports the mitigation of cost and schedule overruns that may surface. Caution must be used as
the project team may be ignoring the warning signs necessary for project recovery.

Schedule Forecasting

When forecasting schedule completions dates, the project team must be aware of the project’s
define critical path. The critical path method is a project time modeling technique designed to
calculate the project’s longest path of activities. The CPM is defined by the relationships that
activities have with each other, and their respective durations to complete the activity. The CPM
calculates the earliest and latest dates that each activity can start and finish without making the
project longer. From this calculation, the total float of an activity is identified (total float is the
amount of time an activity has without delaying the overall timeline of the project).

The main purpose of defining the critical path is to determine which activities are considered
critical. These activities cannot be delayed and are crucial that the team manage properly for
project success.

The following is an example of a basic forecasting approach for schedules:

• Schedule At Completion = Actual Duration + Remaining Duration
• Schedule At Completion = Project Duration ÷ Schedule Performance Index

When forecasting remaining duration, the project team will need to be aware of (to name a few):
• Past performance
• Remaining hours to complete versus available resources
• Material and equipment delivery and support
• Start and finish dates based on activity to activity relationships

iii. Change Management

Change management imposes the required structure and discipline in the project control process
by protecting the integrity of the control basis (performance measurement baseline) as a valid
baseline (i.e., it represents a project plan in alignment with project objectives and requirements)
for performance measurement. The process objective is not to limit or promote change, but to
manage (identify and mitigate) and report it.

The project control plan should address the methodology and processes for managing changes
(whether internal and/or external to the business plan, project or contract) throughout the
project regarding scope, quality, cost and time. The plan will address both the various types of
changes and/or trends, as well as the desired approval process. Change can be positive or
negative, and should always be carefully evaluated. Upon approval, the change should be
methodically incorporated into the revised performance measurement baseline.
Also, change increases the risk that there will be disputes and legal claims; these are generally
detrimental to project performance. Therefore, developing plans and applying methods for
resolving disputes and claims are part of the change management process.

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 15 of 22

December 12, 2011

Due to the importance of managing change within a project, it would be best that a separate
procedure be developed or incorporated to identify the process for supporting the specific
project. At a minimum, the process should provide explanation on the following items:
• Identify deviations, variances, and change
• Analyze variance
• Define deviation or change in scope
• Assess impact
• Record and track disposition
• Manage contingency and reserves
• Resolve disputes and claims
• Revised control basis (PMB)

iv. Project Historical Database Management

A very important aspect of any project is to ensure that the project team prepares the
appropriate close out reports at project completion. This section of the project controls plan
should identify how and who will be collecting the project information. The following is a list of
typical requirements that should be collected:
• Lessons learned, historical from past projects and previous phases / stages (action plans
and continuous improvement strategies)
• Budget and estimate, estimate basis
• Final cost report
• Baseline schedule, schedule basis
• Final schedule
• Final executive project report
• Resource histogram(s), cash curves, progress charts
• Final change order log, complete with costs, hours, and quantities
• Final progress and performance report
• Qualitative and quantitative metrics & analysis (i.e. questionnaires, installed quantities
per discipline or commodity ID, etc.)
• Contractor evaluation report
• Etc.

Implementing the practice of retaining original and final data and records will support the
historical data collection process, and subsequently, improve the delivery of future projects.

3. Systems and Data Integrity Plan

a. Systems

This section of the project controls plan should address how project information will be collected and
processed, as well as identify the systems interface requirements based on the organization, or
within the alliance or joint venture. The plan will describe how information will be transferred
between the systems in order to expedite the data mining process for increased usability and data
integrity. The project controls plan should also describe the systems to be used during the
development, execution and closeout of the project. Each function will be comprised, in part, of the
entire integrated system.

The expectation that the process of how information flows should still be represented in the project
controls plan. The following diagram is an example of how systems will integrate with other systems.

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 16 of 22

December 12, 2011

WBS, OBS, Project Control Accounts, Charter &/or Code of Accounts, etc

Accounting
Estimating System
System

Risk Management
System
(Qualitative &
Quantitative)
Time
Management
Scheduling System
System (Timesheets)

3D Modeling

Procurement /
Contract System
Cost
Management
System
Document
Control

Progressing
System

Historical Database (Qualitative and Quantitative Information)

Figure 2 – Example of Project Controls Systems Integration

The plan should include how information will be mapped throughout the systems, the data collection
cut off times as well as synchronization times. The following identifies some of the types of coding
structures that support the transfer of project data:
• Work breakdown structure (WBS)
• Organization breakdown structure (OBS)
• Cost breakdown structure (CBS)
• Schedule of pay value (SOPV) structure
• Project control accounts
• Code or chart of accounts
• Resource classifications
• Accounting code structures
• Balance sheet
• General ledger
• Taxation and depreciation
• Cost classifications, cost types
• Etc.

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 17 of 22

December 12, 2011

Prior to the start of the project, and depending on the use of the coding structures, the project team
should construct a mapping index that identifies the relationships between coding requirements in
reference to the systems and their requirements. The project team should provide the system
architectural criteria and the validity of the match information (in comparison to all structures).

Also, the plan should also include who will have access and security rights to certain systems within
the project environment. The following identifies some of the types of users that may be assigned to
or support the project:
• Administrators
• Super-users
• Read / write access
• Read access only

The project team may want to use the OBS (organization breakdown structure) or RACI (responsible,
accountable, consulted and informed) chart to determine who can have access to certain project
areas, whether they are geographical or functional.

Please note: Due to effort required for setting up the project systems, it is imperative that the coding
structures identified for use are approved and “frozen” (not to be changed under any circumstances).
Most financial systems are transaction based, and therefore, depending on the size of the project,
thousands of records can be produced in a single day. If the coding structure were to change after the
project has started, the past records (and budgets, mapping, etc) would be required to be corrected
and updated.

b. Data Integrity and Backup

Systems / files are the foundation of most enterprise applications and business processes and contain
some of the company’s most important and sensitive information. In order to ensure a robust
system, as well as reliable, secure and efficient information, the project team should develop a plan
that identifies the responsibility of who is backing up information, what information is being backed
up, the frequency, and the storage requirements.

As part of data integrity, the project team should define how information will be shared between
users. This will include a connectivity plan for computer connectivity. The connectivity plan will
communicate how information will be shared, whether a server is placed on site for network
purposes, stand alone computers are used, or satellite and fiber optics are used.

c. Electronic File Transfer

Electronic file transfer is the transmitting of files over a computer network or the Internet. There are
numerous ways and protocols to transfer files over a network. Therefore, the project controls plan
should communicate how electronic file transfers will be executed. The electronic file transfer
protocol of the project controls plan will describe the convention of how to transfer files between
two computing endpoints.

4. Communications Plan

The purpose of the communication plan is to provide the project team with an understanding as to the
methods and protocols required for conducting communications for the development, publishing,

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 18 of 22

December 12, 2011

reviewing and approval of project information between project team members and the project
stakeholders. The following information should also be included as part of the project controls plan.

a. Meeting Requirements

The purpose of the project meetings table is to provide the project team with the understanding of
meeting requirements to manage the project. An example of meetings and frequency is presented in
the following table. The organization may include more reporting requirements and frequencies
based on the needs of the stakeholders of the project.

Method Frequency
Project team meetings As required, based on project milestones
(at least monthly)
Technical steering team meeting As required to support project milestones
Individual status report Weekly
Weekly project status report Weekly
Weekly change management meeting Weekly
Monthly project status report Monthly
Monthly performance update meeting Monthly
Monthly stewardship and financial update meeting Monthly
Table 1 – Example of Meetings and Frequency

b. Reporting and Frequencies

The project reporting section defines the scope, format, content and responsibilities for the
preparation, submittal and approval on the project reports. This section will also include the required
information necessary to provide management with a period-specific evaluation and consistent
measurement of the plan versus actual and forecast values in terms of overall cost expenditures,
performance and schedule progress, etc. A list of all project reporting deliverables which identifies
the frequency, and who the report is distributed to should be attached to the project controls plan.

c. File Structures

The purpose of the file index structure section is to provide the project team with a repository for
storing information. The project team should fully understand how documents are stored, whether
this is a paper copy, or an electronic copy. Therefore, the file index should include a dictionary that
explains what information is stored where.

5. Project Controls Deliverables

Area Deliverable
Project controls pre-planning and Project controls service agreement (as per functional specifications and client expectations)
preparedness Project controls preparedness index
Project controls kick-off meeting
Project controls Delegation of authority log
Audit calendar
Project control organization
Roles and responsibilities
RACI chart
Coding structures WBS
OBS
CBS

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 19 of 22

December 12, 2011

Code of accounts
Client / 3rd party codes
Estimate and budgets Estimate
Estimate basis document
Estimate risk report, log
Estimate validation report
Budget
Contingency report (drawdown)
Cash flow
Cost report by area, function, classification, estimate hierarchy, etc.
Forecast reports
Schedule Schedule
Schedule basis document
VIP schedule (when VIP's will be introduced)
Schedule risk report, log
Schedule validation report
Schedule reserve report
Forecast schedules
Risk management Risk log
Risk forms
Change management Change log
Change forms
Graphical reports Commodity reports
Resource histogram
Equipment plan (timescale)
Indirect and staffing plan (timescale)
Others Subcontract report
Communications Meeting requirements list
Reporting matrix
File structure
Project calendar
Systems Mapping index
Data synchronization schedule
Backup log
Access and security log
Table 2 – Example of Deliverables that Support Delivery of a Project

The purpose of the communication plan is to provide the project team with an understanding of the
outputs, also known as deliverables that are required for the execution and management of the project.
The deliverables are outputs that support the team in their decision making process to support the
identification of threats and impacts to the project, and determine corrective action where necessary.
Table 2 is a list of deliverables that are used to support the delivery of the project; it is an example only.
The project team may want to add or delete items.

6. Project Controls Plan Implementation

As defined in the TCM Framework, the project control plan implementation is the process of integrating
all aspects of the project control plan; validating that the plans are comprehensive and consistent with
requirements and ready for control; initiating mechanisms or systems for project control; and
communicating the integrated project control plan to those responsible for the project’s work packages.
The following diagram represents the project controls plan implementation process of the Total Cost
Management Framework:

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 20 of 22

December 12, 2011

Project WBS, OBS

Execution Planning
Implementation and Work
Strategy Information Project
Basis Packages Validation
(7.1) (7.2 to 7.7) Implementation
(4.1) (7.1) Metrics
Basis
(10.4)
(4.1)

Document Assess and Review and

Develop Develop Project
Control Plan Optimize Validate
Control Accounts Control Plan
Basis Control Plan Control Plan

Develop and Communicate Plans

Maintain Revised Control and
Implementation Basis Initiate Project
Tools Control Systems

Historical
Changes Basis for Control
Changes Project PLAN
(10.3) (9.1, 9.2,
(10.3) Information
10.1, 10.2, 10.3)
(10.4) ACT DO
CHECK

Figure 3 – Process Map for Project Control Plan Implementation

a. Review and Validate

The project controls plan, control accounts, and documentation should be reviewed and validated by
the project team to determine whether the project controls plan, control accounts, and
documentation provide the required information and is suitable as a manageable basis for control.
The documentation should also be reviewed and validated to ensure that they meet project
objectives and requirements, and whether they are competitive with industry best practices and
historical approaches. The project team may want to introduce a readiness checklist to support the
implementation of the project controls plan.

b. Communicating the Project Controls Plan

At the conclusion of project controls plan implementation, the project controls plan will have been
documented and communicated to the project team, those responsible for work packages will
understand their control responsibilities and their control accounts, and project controls systems and
tools will be set up and ready to support the project controls measurement, performance
assessment, forecasting, and change management processes.

c. Training

The project controls plan should also provide an understanding of the training requirements for the
project team and stakeholders. This training would include:
• Implementation of the project controls plan
• Deliverables; set up; maintenance and use
• Systems; set up; maintenance and use
• Others

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 21 of 22

December 12, 2011

The training plan should identify the project teams training goals, and the expected topics and skills
one would expect from the training. Finally, the training plan should identify the timelines of when
personnel would be trained.

d. Audits

Once the project controls plan has been approved, it is recommended that a separate entity audit the
project team to ensure compliance of the project controls plan throughout the delivery of the
project. If items within the project controls plan are no longer warranted, then the project controls
plan will need to be updated and redistribute. A list identifying who will be performing the audit and
the frequency at which the audit(s) will take place should be attached as part of the deliverables for
the project controls plan. The audits will provide valuable information as to what is working well,
what isn’t working well, what needs to be changed and what needs to be deleted. The audits should
also provide an understanding as to compliance, and the reasons for non compliance, such as:
• Process Design – Is there a flaw in the project controls plan, implementation or monitoring?
• Resource Constraint – Is there a lack of resources to complete the deliverables as identified
by the project controls plan?
• Training Requirements – Is there sufficient skill, training, or knowledge to ensure
compliance?
• Process Discipline – Is the project team displaying proper process discipline to carry out the
deliverables as identified by the project controls plan?

SUPPORTING INFORMATION FOR DEVELOPMENT AND IMPLEMENTATION

The following is a list of procedures that may be developed to support the use and implementation of the project
controls plan:
• Team development procedure • Risk management procedure
• WBS development procedure • Value improving practices (VIP) procedure
• Project control account development procedure • Accounting and invoicing procedure
• Estimate and budget development procedure • Financial stewardship procedure
• Schedule development and management procedure • Contingency management procedure
• Cost management procedure • Claims and dispute resolution procedure
• Change management procedure • Project closeout procedure
• Progress measurement procedure • Historical data collection and benchmarking procedure
• Performance assessment procedure • Communication procedure
• Forecasting procedure • Systems integration procedure
• Purchasing / contract administration procedure • Audit / compliance procedure
• Glossary of terms, acronyms and formulas

REFERENCES

1. AACE International Recommended Practice No. 10S-90 Cost Engineering Terminology, AACE International,
Morgantown, WV, (latest revision)
2. H. L. Stephenson, Ed., Total Cost Management Framework: An Integrated Approach to Portfolio, Program and
Project Management, 2nd ed., Morgantown, WV: AACE International, Latest revision.
3. Amos, Dr. Scott J. (Editor), AACE International, Skills & Knowledge of Cost Engineering, 5th Edition, 2004.
4. O’Brien, James J., Plotnick, Fredric L., CPM in Construction Management, 7th Edition, New York: McGraw-Hill,
Inc. 2010.

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.
60R-10: Developing the Project Controls Plan 22 of 22

December 12, 2011

5. Westney, Richard E., The Engineer's Cost Handbook: Tools for Managing Project Costs, New York: Marcel
Decker Inc., 1997.
6. Humphreys, Kenneth K., Project and Cost Engineer’s Handbook, 4th Edition, New York: Marcel Decker Inc.,
2005.

CONTRIBUTORS

Disclaimer: The content provided by the contributors to this recommended practice is their own and does not
necessarily reflect that of their employers, unless otherwise stated.

H. Lance Stephenson, CCC (Primary Contributor)

John K. Hollmann, PE CCE CEP
Michael A. Farin
Rob Hartley, PSP
Rajasekaran Murugesan, CCE
W. James Simons, PSP

Copyright © AACE® International AACE® International Recommended Practices

Single user license only. Copying and networking prohibited.