Baseline Management and Change Control: A Performance Imperative

Home  >>  Change Control  >>  Baseline Management and Change Control: A Performance Imperative

Baseline Management and Change Control: A Performance Imperative

On November 23, 2016, Posted by , In Change Control, With No Comments

The implementation of Earned Value Management in today’s enterprises is enabling program and project leaders to measure the performance of a program at a high degree of granularity. Yet still we see too many programs and projects spiral out of control due to external forces and supporting processes that are not effective.  Volatility and change are two of the biggest drivers of performance erosion in a program or project.  Change comes from many different sources and every change must be captured and dealt with in a conscious manner, and while the changes themselves can be complex and numerous, the process for controlling and managing change is quite simple.

Hence, a strategic imperative in achieving success in program execution using Earned Value Management is to have an agile and disciplined baseline management and change control process. While different program or project types and sizes may require higher or lower degrees of baseline control to manage performance, the core set of baselines in typical system development programs that drive performance tend to converge on the core set listed below.  It’s important to note that no baseline stands alone.  Change to one baseline will almost always ripple into other baselines.

1. Contract Scope Baseline

Whether it’s building a house or a high-performance weapon system, contract scope change is inevitable. Controlling the scope of work in every contract is vital to ensuring that the contract target cost, schedule are modified to reflect changes in scope, and that no additional risk is imposed in achieving compliance with technical or other contract objectives.

2. Technical Baseline (Requirements, Performance Measures, Design, Product)

As programs mature, even beyond cementing the allocated requirements and preliminary design baseline, more knowledge is acquired in terms of risks, issues and opportunities leading to requirements and design change. These changes must be captured and analyzed before their approval to ensure that the total impacts of the change are understood and accounted for, and that the change is implemented in an orderly and timely manner.

3. Target Cost (BAC + Contingency + MR) and Budget Baseline (BAC)

While any change to any baseline is highly likely to have some impact on target cost, changes in cost performance can also drive change to other baselines as a corrective action to restore cost performance. These changes must also be evaluated as any other change.

4. Schedule Baseline

As with cost, changes to any baseline will likely have an impact on the schedule. If schedule performance begins to degrade, recovery actions will often require change to the other baselines as well.

5. Organizational and Responsibility, Authority & Accountability (RAA) Baseline

The organizational baseline, often overlooked from a control perspective, is vital to an Earned Value Management System representing who and what skills is doing what work when, and how tasks in one part of an organization support tasks in another. It is also vital to enable the required communication within and outside the organization, how decisions are made, who is authorized to make those decisions and how conflicts are escalated and resolved. A good Communication Plan is often recommended or even required for larger programs. Lapses or breakdowns in organization or communication will certainly impact other baselines and lead to degraded performance.

6. Risk Management Baseline

As discussed in previous articles, a solid risk management plan and process is vital in achieving performance excellence. It is also important that the risk register and mitigation plans be controlled as a baseline, especially in high risk technology development programs. The risk mitigation efforts need to be funded and accounted for in the program schedule, and completion of the mitigation steps along the way need to be monitored to ensure the risk is actually being reduced as planned.

7. Process Baseline

How the work is to be performed is as critical to performance as the work itself. It is vital that the baseline budget, schedule and technical performance baseline are established with well-defined processes documented that describe how each major task is performed. As the program matures, these processes should be measured, monitored and modified for corrective action or continuous improvement. Changes to process must also be implemented in a rigorous manner with all impacts evaluated and accounted for.

8. Quality Baseline

From day one on the program, a Quality Program Plan must be put in place to describe how even through the requirements development and design phase, quality and mission assurance requirements are going to be achieved and sustained. Changes to any other baseline must be evaluated for their impact on quality, and improvements to quality standards/requirements must also be evaluated in terms of their impact on the other performance baselines.

The change control process itself is quite straightforward, and provides a means for rapid review and approval of change. The CCB is typically held weekly on volatile projects where a lack of specificity in the Contract SOW drives a need for change, consists of the leadership on the projects, and is chaired by the Program or Project Manager. Occasionally, the level of authority required to approve a change may exceed the authority of the Program and Project Manager. In these cases, the appropriate member or members of Senior Management can be included to effect approval of the change. The steps in the process are described below:

A. Generate Program Change Request

Irrespective of the source of the change, the discipline to capture and document that change must be instilled as a value by each member of the team. The Program Change Request (PCR) is one example of a document used to propose a change to any of the performance baselines or controlled documents and processes. The PCR describes the proposed change, everything affected or impacted by the change, the cost of implementation, the effectivity of the change and the overall benefit to the project.

B. Pre-Board Review

At the CCB, held as needed, weekly or monthly, whichever is more frequent, there are two phases of review and approval. The initial step is referred to as a pre-board review. At pre-board, new PCR’s are reviewed to determine if they warrant consideration, and what further analysis or impact evaluation is required. If so, the actions and assignees are documented and the PCR’s are approved to move to the next phase of detailed estimating or any other action spawned by the CCB. If not, they can be disapproved prior to any significant effort expended or cost incurred.

C. CCB Approval Review

The second phase of review is the final approval of a change and a plan and schedule for implementation. Once a mature operating rhythm in the CCB is achieved, this phase will be a “rubber stamp” exercise, but does give the board a formal mechanism to evaluate the cost vs. benefit of implementing the change, and based on that evaluation, approve or reject the change.

D. Documentation and Approval Record

For all changes, the CCB chair will sign a Program Change Summary, documenting approval of the proposed change. The Program or Project Manager may also be required to issue program authorizations in the form of Program Management Orders, Engineering Orders, and Manufacturing Orders as well as updated Program Directives for cost and schedule changes to ensure that implementation is backed by project authority.

E. Master Change Log

Given the accumulation of changes on a given project, especially those with high volatility, a Master Change Log (MCL) will be maintained to enable review of all project changes proposed, in process, disapproved and approved. The MCL will also provide for the collection of aging metrics to determine if there are any pitfalls or bottlenecks in the change control process. These metrics, if collected, should be reviewed at least monthly and improvement plans put in place to resolve process issues or improve process quality.


Leave a Reply