Project Re-Baselining Guidelines (GM-22-001)

GM-22-001 Project Financial Management Guidelines

Issue Date:  8/01/2008

Review Date: 12/02/2022

PURPOSE

The purpose of this document is to provide guidance on the appropriate application of re-baselining techniques on complex IT projects within the State of Georgia.  The PMBOK ® Guide states a baseline is defined as an integrated scope, schedule, cost plan for the project work against which project execution is compared to measure and manage project performance.  It is essentially putting a stake in the ground; committing to the plan.

SCOPE and AUTHORITY

O.C.G.A 50-25-4(a)(8) – State Government, Georgia Technology, General Powers

O.C.G.A 50-25-4(a)(11) - State Government, Georgia Technology, General Powers

O.C.G.A 50-25-4(a)(20) - State Government, Georgia Technology, General Powers

O.C.G.A 50-25-4(a)(28) - State Government, Georgia Technology, General Powers

PM-04-001 – Information Technology Policies, Standards and Guidelines

PS-08-005 – Enterprise Information Security Charter

GUIDELINES

A baseline is the approved version of a work product or plan.  Actual performance is compared to baselines to identify variances. The project baselines include but are not limited to the following:

• Schedule baseline –The approved version of the schedule model is used as a basis for comparison to the actual results.
• Costs baseline – The approved version of the time-phased project budget, excluding any management reserves, which can be changed only through formal change control procedures and is used as a basis or comparison to actual results.
• Scope baseline – The approved version of a scope statement, work breakdown structure (WBS), that can be changed using formal change control procedures and is used as the basis for comparison and actual results.  
• Performance measurement baseline – Integrated scope, schedule, and cost baselines are used for comparison to manage, measure, and control project execution.

RECOMMENDED RE-BASELINING GUIDELINES:

• Large projects should be planned progressively
• When the vendor is developing the product, the Agency Project Manager should plan and baseline a high-level complete project life cycle including the vendor procurement activities.
• An original baseline and at least 1 re-baseline is a normal part of project planning and execution for large complex projects.  Microsoft Project scheduling tool can save multiple baselines which allows the ability to retain previous baselines for historical purposes.
• Large complex projects should have a Governance Board, usually Change Control Board (CCB), and defined processes to review re-baseline requests.
• Projects must have a change request for each re-baseline that explains the purpose, basis, and explanation of the change.
• Even with a re-baseline, an archive should be maintained for tracking of lessons learned and auditing purposes when looking back over the full project life cycle.
• After the project plan is baselined, it can only be changed through a formal change control process

WHEN SHOULD A PROJECT BE BASELINED?

The initial baseline should be set after the project plan is finalized and before Execution. The concept of "finalized" is not absolute when it comes to planning due to iterative and progressive development methodologies. Once the project plan is finalized and approved by Stakeholders, the baseline is set. When a baseline is set, schedules, budget, and scope do not change EXCEPT through an integrated change control process. A baseline reset might occur as a result of this process.

The State of Georgia encourages the use of progressive planning for large complex multi-year, high-dollar projects (usually over $1mm). It is essential to remember that the whole of a base plan is not going to be implemented at once. It is important to preserve flexibility and avoid making commitments before more information is known. Base plans which develop detail before it is needed tend to inhibit flexibility. Hence, a key step in planning is deciding what has to be decided now, what has to be decided later and what can be flushed out at a later time. This technique is called "Progressive Elaboration", which means increasing the level of detail in a project management plan as greater amounts of information and more accurate estimates become available. This method of planning creates a more reliable plan, minimizes the risk of unacceptable performance variances and the need to re-baseline often.

WHEN SHOULD A PROJECT BE RE-BASELINED?

During the course of executing the original baselined plan, the plan may become so far off the track of actual execution that the plan is no longer realistic or achievable. The need to re-baseline the original baselined plan to create a new baseline plan for project execution may be needed.

Two situations that may cause a baselined plan to become unrealistic and unachievable are new information and an unachievable plan.

1. As planning is done progressively, the team may discover new information that is significant and was not reflected in the original baselined plan.
2. During the execution of baselined plans, the current project performance (Where I Am Now) is so far off from the expected performance (Where l Should Be) that the plans are no longer achievable or realistic. This is usually shown in project schedule performance tracking.  Some reasons for the variance between planned and actual might be major scope changes or lengthy delays.

WHO DETERMINES WHETHER TO RE-BASELINE?

After the project plan is baselined, it can only be changed through a formal change control process. All changes to the baseline must be reviewed and approved by a formal governance process:

• First, the project Change Control Board (CCB) must approve; and
• This approval must also be vetted with the Critical Project Review Panel.

The CCB must define and communicate criteria for determining whether the request to re-baseline will be accepted or rejected.

An example of a valid reason for re-baselining projects within the State of Georgia are:

1. Approved scope change submitted after the original baseline is approved by the CCB.
2. A contract amendment has caused the project plans to deviate from the baselined plans.
3. The original baseline reflected high-level planning estimates of the project plan prior to the procurement of the Vendor. After supplier onboarding, more detailed planning and estimation should incorporate Supplier input and more realistic dates.
4. The Project team cannot get the project back on track using any project management techniques (concurrent processing, adding more resources, etc.) The baseline will always be unachievable.  Poor Performance and Poor Planning are NOT reasons to re-baseline.  In some situations, stakeholders may not agree to re-baseline if the project baseline is unachievable due to poor performance.  If the cause of the variance is determined to be outside the control of the project team, re-baselining the plan may be valid. 

COMMON RE-BASELINING MISCONCEPTIONS 

1. Re-baselining changes past performance.

Response: Poor performance in the past will still be reflected in the project status reports. Re-baselining only impacts future plans.

2. Re-baselining allows a Project Manager to adjust future dates to conceal poor project performance.

Response: An effective Change Control process requires the decision to be made by several people and is not a unilateral decision.

3. Re-baselining indicates poor performance or a failed project.

Response: At least one re-baseline is a normal part of project planning. Multiple re-baselines may be needed for projects that have very long durations. Excessive re-baselining may be an indication of a serious problem.

RELATED ENTERPRISE POLICIES, STANDARDS AND GUIDELINES

SM-08-006 Technology Project Management

GM-17-002 Project Scheduling Guideline

TERMS AND DEFINITIONS

Baseline - The original approved plan for a project, work package, or activity plus or minus approved scope change usually used with a modifier (i.e. cost baseline, schedule baseline, performance measurement baseline).

Change Control Board (CCB) – A formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions.  A CCB is a group of stakeholders responsible for approving or rejecting changes to the baseline project plan. The Project Manager typically functions as the CCB Chairperson.

Progressive Elaboration or Progressive Planning or Rolling Wave Planning-The iterative process of increasing the level of detail in a project management plan as greater amounts of information and more accurate estimates become available. Commonly, less information is usually known earlier in the project planning phases and information becomes more defined through iterative planning.

Re-baseline - Same as Baseline but done after the initial baseline is done as a project monitoring and control technique.

Work Breakdown Structure (WBS) – A hierarchical decomposition of the total scope o work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

REFERENCES

Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide)