When client and contractor start throwing accusations against each other surrounding schedule baseline, one can easily conclude that a problem or issue is brewing. It can turn into big risks (Frago, Schedule Baseline Dilemma Part 1, 2015). Resolving the contentions between opposing parties can take long and potentially, can end in disaster.
To prevent such occurrence, the project must start with the right foot forward. The project manager, all his planners, and schedulers, including his contract administrators must have a solid understanding on how the project intends to manage schedule baselines.
If baseline management is not part of the plan, the project is trekking on dangerous territory.
A project that does not have a clear understanding on how to manage schedule baselines cannot expect to manage time effectively.
In continuation of my previous article Schedule Baseline Dilemma Part 2 where we tackled questions surrounding baseline management, I would like to present to you what I believe should be the ten cardinal rules to baseline management.
Types of Schedule Baseline
The Oracle Primavera Project Management scheduling tool offers good handle and flexibility maintaining and assigning baselines.
It is best for a singular point of contact called the Primavera Database Administrator to assign the types of schedule baseline. Assign this responsibility as soon as conveniently possible and maintain its existence going forward.
Changing and streamlining the existing list and description will automatically apply to all existing baselines already assigned to their respective projects. Do the modification only when absolutely needed.
Figure 1 shows an example list of baseline types created by the assigned Primavera Administrator. This makes labeling baselines easy. It also prevents confusion as to the intention of each baseline.
Figure 1 – Baseline Types (Example List)
Only the Primavera Administrator has the right to change the list and description of baseline types. He is more effective as part of the Project Control-Governance Team. P6 Users do not have access to change Baseline Types.
It is best to identify the types of baseline through close collaboration between the projects PC Leads and PC Governance as their application becomes one of the cornerstones of BL management.
After the list is agreed-to, there is little to change in the future. It becomes part of the database configuration and the schedule baseline protocol.
The term “User/s” in this article is the person using the Primavera scheduling tool.
BL = Baseline
SBL = Schedule Baseline
EDS = Engineering Design Specifications
FEED = Front End Engineering Design
SRA = Schedule Risk Analysis (also called SQRA)
SQRA = Schedule Quantitative Risk Analysis
Project Management (Primavera 6.1 SP1, 6.2, 6.7 SP1, 6.7 SP2, SP5 and higher)
Ten Cardinal Rules
- Make sure baselines are static
Keep the all schedule baselines as static reference files under the current schedule all the time.
- Assign the Project’s Official Baseline to the Project Baseline field.
Always assign the project’s official baseline to the Project Baseline field . This does not prevent the P6 User from assigning the official baseline in one of the ad-hoc baseline fields. Ensuring that the official baseline occupies the correct field prevents error when making quick analysis. Do not put any ad-hoc baseline into that field.
Figure 2 – Project Baseline (Assign Baseline Dialog Box)
3. Back up original, official and gate baselines
Back up project baselines and save in the project’s common working folder. This back up is important in case of remote instance that the static file is inadvertently changed, deleted, or misplaced.
4. Only the lead planner/scheduler assigns baselines
The Lead Planner/Scheduler or equivalent PC Lead assigns the schedule baseline. Central control is essential to avoid mishandling baselines.
Figure 3 – One Point of Contact (Singular Responsibility)
The baseline is the project’s approved version. It shall have buy-ins of all essential stakeholders.
5. Do not maintain live baselines
Avoid maintaining official schedule baselines as live files in the scheduling database. This prevents potential changes made to it by curious and uninformed Users working in a common environment (read Section 1)). If it becomes unavoidable, the baselines must be locked/secured.
6. Do not change or modify original, official or gate baselines
An official baseline is a schedule target that should not be changed. Nobody should change an approved baseline. Always remember that officially approved baselines are fixed. Nobody touches it. They stay as reference targets as long as they still make sense and have values.
If an existing baseline is no longer workable for whatever good and valid reason, a re-baseline becomes one of the typical solutions accompanied by an approved management of change document.
Although the usual terminology used is “changing the baseline”, one must understand that it is actually referring to versioning the original official baseline.
Versioning is not changing the existing baseline. It is redefining and approving the remaining part of the schedule, eventually coming up with a re-baseline.
The old baseline is good until the last data date update where it was replaced while the new version that replaced it is good from the data date it was approved onward until the contractual end date, project end date or until such time that another re-baseline becomes necessary.
Figure 4 – Never Change the Official Baseline
A changing baseline is a moving target and makes it hard for the project to manage the current schedule. It creates confusion and a potential contractual dispute.
Schedule re-baseline is versioning of the existing baseline.
It is a copy of the existing baseline with amendment starting from the last data date. The amendments are according to what is required to be added, deleted, or modified.
The re-baseline is a version of the replaced baseline. It is distinct and separate, saved with a different baseline ID and name description.
The previous baseline remained intact and considered archived. That baseline is true up to the data date line while the revision takes its place as the assigned baseline from the data date onward.
7. Do not calculate (F9) a restored EXISTING baseline
Not all baselines were properly developed. Top-notched planners and schedulers are not always easy to come by.
Sometimes one will come across a baseline without logic, more a checklist than a schedule. Many have missing ties with haphazardly thrown around milestones sitting precariously on the timeline without support or perhaps, a schedule laden with strange constraints.
If you are new to the project, orient yourself or ask for orientation.
If any User calculate (F9) such a restored baseline, the activities and dates will move around and the project will lose the baseline information.
Although not expected in a properly prepared schedule, one should take precaution and not be surprised that such a schedule baseline exists!
This is one primary reason why a baseline has to remain static (read Section 1.
So be warned!
8. Changes to the current schedule does not changing the baseline
Confusing a normal schedule maintenance and update to changing the baseline or manipulating the baseline schedule must not happen. In brief, changes to the current schedule are not changing the baseline. Do not let this be the source of dispute between contractors and clients.
The project changes the current schedule to deliver the target deliverables successfully. If a point in time comes that no adjustment to the current schedule can bring it back to target, then a re-baseline might be the only option. A re-baseline affects all parties in varying degrees.
9. Avoid restoring an official project baseline already embedded in the current schedule
The temptation to restore an already assigned static official project baseline comes to fore every now and then. It is not a good idea.
When a static baseline becomes live, inadvertently changing the BL becomes more real (review preceding items 1, 5, and 6).
Do the baseline restoration carefully. If the BL has no XER backup, create one.
Caution: See item 7.
10. Run a P6 Baseline Audit
Run random audits of the official project baseline or in cases where there is reason to suspect that someone has changed the baseline. The project needs this quality test to revalidate reliability of the existing baseline data.
Compare restored BL versus Back up BL using claim digger, Acumen Fuse, or similar tools. Some third party IS Support can provide customized P6 auditor that can pinpoint what a User did.
Rufran C. Frago – Author (Rev. 1, 18-Apr-16, Rev. 0, 05-Dec-15,)
Schedule Critical Path by Rufran C. Frago
Setting Critical Path by Rufran C. Frago
Effects of Constraints on the Critical Path by Rufran C. Frago
Rufran is the author of the book Risk-based Management in the World of Threats and Opportunities: A Project Controls Perspective.
For those who are interested, please join Rufran at (click hyperlink) the following sites.
- LinkedIn Risk-based Management (RBM) Group
- My Oil Pro
- Risk-based Management and Services Inc. Facebook
- Your World, Our Risk Universe: WordPress
- E-Touch Up: A Brand of RBM&S Inc.
- Author Page: Amazon.com
- LinkedIn Professional Website
Related articles authored by Rufran Frago.
- Schedule Critical path
- Primer to Good Schedule Integration
- Project Schedule: P50, Anyone?
- Schedule Baseline Dilemma Part 1
- Schedule Baseline Dilemma Part 2
- 4D Scheduling Part 1: What is it about?
- 4D Scheduling Part 2
- 4D Scheduling Part 3
- Risks as a Function of Time
- Project Schedule: P50, Anyone?
- Mega-Projects Schedule Management and Integration
- Scaffolding Hours: What are they? Part 1
- Scaffolding Hours: What are they? Part 2
- Oil Price, Recession: Causes, Issues and Risks
- Your World, Our Risk Universe
- Rufran Frago in the Global Risk Community Site
- Earthquakes, Super Typhoons and Fundamentals of RBM