TCMFramework_SM.gif (5258 bytes)TCM Framework: An Integrated Approach to Portfolio, Program and Project Management
(Rev. 2012-01-09)
[AACE HOME] -- [TCM HOME] -- [BUY THE TCM FRAMEWORK] --[DOWNLOAD PDF VERSION]

[TOC] [PREVIOUS] [NEXT]

III. PROJECT CONTROL PROCESS - CHAPTER 8 - PROJECT CONTROL PLAN IMPLEMENTATION

8.1 Project Control Plan Implementation

8.1.1 Description

    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. This process initiates project control for the current project phase for which work has been authorized by the project implementation process (Section 4.1). For example, control plans may be implemented at the start of each successive planning phase and then again prior to the final execution phase.

.1 Control Accounts

    A key concept for project control plan implementation is the control account that functionally integrates 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. However, a control account may include one or more work packages that are in the same branch of the WBS hierarchy and for which the same person in the OBS is responsible. Figure 8.1-1 illustrates the control account concept at the project execution phase.

Figure8.1-1.jpg (137797 bytes)

Figure 8.1-1 Example of the Control Account Concept
[LARGER IMAGE]

.2 Phased Control

    As discussed in Section 4.1, the project implementation process uses phases and gates wherein a gate review is conducted at the end of each phase that results in updated direction (i.e., a decision to proceed to the next phase, request for additional work or information, or a halt to the project) and resource authorizations (i.e., phased project funding). After funds for a phase are authorized, the work for that phase usually begins in earnest. Therefore, a key concept for project control plan implementation is phased control, 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.[59]

    For example, project control planning for the project execution phase (e.g., detailed engineering and construction) is performed during the preliminary design phase, and planning for the control of the preliminary design phase during the conceptual phase. Because the scope of work during the early phases is usually limited in extent (e.g., first or second level of the WBS, few people on the project team, few material purchases or contracts, etc.), project control planning is a simpler process than for the later execution phase when most of the work will be done.

8.1.2 Process Map for Project Control Plan Implementation

    Figure 8.1-2 illustrates the process map for project control plan implementation. The primary inputs are control plan components and the primary outputs are control accounts, which are part of an integrated basis for project control for the next phase of work.

    As was discussed, this process and the other project control planning processes are applied in a phased manner as project work is implemented (Section 4.1). Also, the input from the change management process (Section 10.3) is intended to illustrate that changes to the project control plan basis may be made that require implementation of a "revised" control plan. Implementations driven by changes follow the basic process but, depending on the scope of the changes, mid-phase implementation is usually quick with less effort. For mid-phase changes, the words "Maintain" or "Revise" apply to the steps rather than "Develop." However, the importance of communicating plan revisions to the project team is no less than for the initial plan implementation.

Figure8.1-2.jpg (115255 bytes)

Figure 8.1-2 Process Map for Project Control Plan Implementation
[LARGER IMAGE]

    The following sections briefly describe the steps in the project control plan implementation process.

.1 Develop Control Accounts

    At the start of the process, the control accounts (see Section 8.1.1.1) are developed by the project control person or team. The process is generally more iterative with the various project control planning processes (Sections 7.1, 7.2, 7.3, 7.4, 7.5 and 7.6) than indicated by Figure 8.1-2. As indicated by the "feedback" arrows, as the control accounts are developed, improvements to various aspects of the control plan may be made. Also, as discussed, if the process is initiated by a change, then control accounts are "maintained," rather than developed.

.2 Develop Project Control Plan

    While control accounts functionally integrate the working aspects of the plan’s components, a control plan procedure is also developed to communicate the plan. This deliverable is part of an overall project execution plan (PEP) that describes specific approaches that each functional entity (engineering, procurement, construction, safety, quality, etc.) will use. The project control plan is part of the PEP. The PEP is an extension of the execution strategy defined during scope development (Section 7.1).

    The control plan describes specific systems and approaches to be used in project control. The plan is more of a narrative or qualitative representation (i.e., a communication tool) of the project control plan, while the control accounts, estimate, schedule, and so on represent the quantitative aspects.

    The control plan will also outline both the control systems and the reports to be used. The control systems will have policies, procedures, and other aspects that guide and support effective project control.

.3 Document Control Plan Basis

    The basis of the control plan components (i.e., cost, schedule, resources, risk, and procurement) and control accounts must be documented. This document describes how the control plan component was developed and defines the information used in support of that development. This document commonly includes, but is not limited to, a description of the scope included, methodologies used, references and defining deliverables used, assumptions and exclusions made, clarifications, adjustments, and some indication of the level of uncertainty. The basis of the plans and accounts must be well defined so that proposed changes can be evaluated to determine if there really is a change, and if so, to what extent (Section 10.3).

.4 Review and Validate Control Plan

    The project control plan, control accounts, and documentation are reviewed by the project team to determine whether they are complete and suitable as a manageable basis for control, whether they meet project objectives and requirements, and whether they are competitive with industry best practices and historical approaches (i.e., validation). A useful tool for reviews is a readiness checklist for the project control function that helps assess that all aspects of the plan are complete and ready for implementation in all regards.

    It is a challenge to develop "manageable" control accounts and systems. If measuring, reporting, and/or assessing control data is too burdensome (e.g., too detailed, frequent, difficult to understand, etc.), the process can stop working effectively (i.e., "analysis paralysis") and/or those responsible for the work will find ways to work around the project control system. Conversely, if the information is not detailed or frequent enough, or tools are inadequate, the control exercise can also become meaningless. Either way, the project is at risk for getting out of control. A good way to help determine if project control plans and accounts will be "manageable" is to develop and maintain standards and/or templates for successful approaches based on historical practices as captured in a historical database (Section 10.4).

    Validation is applied specifically to plans to assess whether the plan results are appropriate and achieve the performance objectives. Validation usually involves benchmarking, which is a process that compares practices, processes, and relevant measures to those of a selected basis of comparison (i.e., the benchmark) with the goal of improving performance. The comparison basis includes internal or external best practices, processes, or measures. In validation, the "relevant measures" used are referred to as metrics; these metrics are developed in the project historical database management process (Section 10.4). While each plan element is usually reviewed and validated separately as it is developed; the project team should review and validate the integrated plan as a whole before implementation.

.5 Communicate and Initiate Project Control Systems

    Those responsible for work packages must understand the project control plans and their control accounts. Those responsible for interfaces with the project control process (e.g., business accounting and financing) also need to understand those aspects of the project control plan that affect them. The PEP, including the project control plan, facilitates understanding; however, training may be required in the roles and the tasks that various responsible parties need to perform in support of project control.

    If the responsibility for a work package lies with a supplier or contractor, the procurement planning process (Section 7.7) will have defined all the interfaces of the suppliers and contractors with the project control process. Suppliers, sub-contractors, and contractors generally prepare their own control plans and control accounting. However, these must be consistent with the overall control plans and control accounting to the extent required by the contract.

    Once all parties are ready for control, the project control leader integrates the plans into mechanisms or systems for control. Information technology tools are at the core of the systems including software for scheduling, cost/schedule reporting, and project cost accounting as well as working databases used for or interfacing with this software. Initially the databases will contain the budgeted value, schedule, and resource data (these working databases are generally separate from the historical databases described in Section 10.4). As the project progresses, actual measured data are captured for assessment against the plans. At implementation, information security mechanisms must be established to control who may enter, change, delete, view, or otherwise use data and information in or from the database. In addition, the interaction/interface of owner, supplier, and contractor systems must be considered and resolved.

    At the conclusion of project control plan implementation, the project control 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 control systems and tools will be set up and ready to support the project control measurement (Sections 9.1 and 9.2), performance assessment (Section 10.1), forecasting (Section 10.2), and change management (Section 10.3) processes.

    It is important to note that no resources or funds should be committed without appropriate plans, budgets, and authorizations, as communicated by an initiation process such as described in this section.

8.1.3 Inputs to Project Control Plan Implementation

.1 Project Implementation Basis. The project implementation process (see Section 4.1) provides the asset scope, objectives, constraints, and assumptions basis for the project, as well as authorizing funds and resources. The project control plan must be consistent with the requirements established for the project.

.2 Execution Strategy. This defines the general approaches through which the work packages will be performed (Section 7.1); the project control plan must be consistent with the agreed upon approaches.

.3 WBS, OBS, and Work Packages. These deliverables from the scope development process (Section 7.1) define the scope of and responsibility for the control accounts.

.4 Planning Information. Project planning provides information that is incorporated in the control accounts. Schedule activities are inputs from schedule planning and development (Section 7.2), budgeted costs are input from cost estimating and budgeting (Section 7.3), and resource quantities are inputs from resource planning (Section 7.4). While each planning process considers risk, the risk management plan (Section 7.6) is also a component of the project control plan. Procurement planning (Section 7.7) defines supplier and contractor requirements for project control planning and control accounting.

.5 Changes. During project execution, changes to the baseline scope definition and plans are identified in the change management process (see Section 10.3). Each change goes through the project control planning processes so that it can be appropriately integrated into the project control plans and accounts.

.6 Validation Metrics. Historically based benchmarks and metrics (Section 10.4) are used in the validation step.

.7 Historical Project Information. Successful past project control plans and control account approaches are commonly used as project control plan implementation references.

8.1.4 Outputs from Project Control Plan Implementation

.1 Basis for Project Control. The project control plan and control accounts are integrated into systems for control. Information technology tools are at the core of the systems including software for scheduling cost/schedule reporting and project accounting, as well as databases used for or interfacing with software. The basis for project control also includes policies, procedures, and other documents that guide and support effective project control.

.2 WBS, OBS, and Work Packages. As control accounts are developed, improvements may be identified.

.3 Planning Information. As control accounts are developed, improvements to any of the project control planning components may be identified.

8.1.5 Key Concepts for Project Control Plan Implementation

    The following concepts and terminology described in this and other chapters are particularly important to understanding the project control implementation process of TCM:

.1 Control Accounts. (See Section 8.1.2.1 and Figure 8.1-1).

.2 Project Control Plan. (See Section 8.1.2.2).

.3 Project Execution Plan (PEP). (See Section 8.1.2.2).

.4 Basis. (See Section 8.1.2.3).

.5 Validation. (See Section 8.1.2.4).

Further Readings and Sources

    Project control plan implementation is generally covered in project management, project control, and project planning and scheduling texts, and not as a subject in itself. It is included as a separate process in TCM to highlight the importance of assuring that all aspects of the project control plan are integrated and validated as a whole, a step that is sometimes overlooked in treatments that focus on separate project control functions.

[TOC] [PREVIOUS] [NEXT]

Copyright © 2008 By AACE® International www.aacei.org
Comments/more information on the TCM Framework: An Integrated Approach to Portfolio, Program and Project Management may be directed to tcm@aacei.org