Ten Cardinal Rules to Good Schedule BL Management

050216-BL7

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)

Warning!

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.

Definition

The term “User/s” in this article is the person using the Primavera scheduling tool.

Acronym

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

Scheduling Tool

Project Management (Primavera 6.1 SP1, 6.2, 6.7 SP1, 6.7 SP2, SP5 and higher)

Ten Cardinal Rules

  1. Make sure baselines are static

Keep the all schedule baselines as static reference files under the current schedule all the time.

  1. 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)

Reminder:

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.

Reminder:

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.

Warning:

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.

TIP:

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,)

Additional reading

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.

Related articles authored by Rufran Frago.

  1. Schedule Critical path
  2. Primer to Good Schedule Integration
  3. Project Schedule: P50, Anyone?
  4. Schedule Baseline Dilemma Part 1
  5. Schedule Baseline Dilemma Part 2
  6. 4D Scheduling Part 1: What is it about?
  7. 4D Scheduling Part 2
  8. 4D Scheduling Part 3
  9. Risks as a Function of Time
  10. Project Schedule: P50, Anyone?
  11. Mega-Projects Schedule Management and Integration
  12. Scaffolding Hours: What are they? Part 1
  13. Scaffolding Hours: What are they? Part 2
  14. Oil Price, Recession: Causes, Issues and Risks
  15. Your World, Our Risk Universe
  16. Rufran Frago in the Global Risk Community Site
  17. Earthquakes, Super Typhoons and Fundamentals of RBM

and more…

Advertisements

About rcfrago

Rufran C. Frago, P. Eng., PMP, CCP, PMI-RMP, is the Managing Director of RBM&S Inc., a young Calgary company focusing on risk-based management consulting services, and online merchandising. He has many years of international industry-related work ‎experience in Oil & Gas, Petrochemicals, Oleo-chemicals, Sugar Refining, Manufacturing, Consulting, and Education. He has worked in various parts of the world (Location: Asia, Middle East, Canada, and North Africa). Rufran has worked with Caltex, Uniman, Unichem (now Cocochem), ARAMCO-KSA, Central Azucarera de Tarlac, Arabian Gulf Oil Company-Libya, Batangas State University, Saint Bridget’s College, JG Summit Petrochemicals, Halliburton-Kellogg, Brown and Root, OPTI Canada, and Suncor Energy Inc. His expertise includes risk-based project management, risk analysis, planning & scheduling, cost management, auditing, maintenance, operation, EH&S and reliability engineering. He is interested in providing solutions and innovations to all clients and stakeholders. Rufran is the author of the books “Risk-Based Management in the World of Threats and Opportunities: A Project Controls Perspective” and "How to Create a Good Quality P50 Risk-based Baseline Schedule" published in 2015 and 2017. Mr. Frago is a Filipino-Canadian risk management practitioner. He studied at BSU graduating with a Diploma in Petroleum Refinery Maintenance Technician, and BS Mechanical Engineering. He was also a BS Management Engineering graduate of UB. He took up MBA courses under UP-PBMIT Consortium. Rufran completed Computer Technician Program at ICS-Pennsylvania, USA, APM Certificate program at SAIT-Calgary, and PM Certificate program-Construction Management. He is presently taking up PM Certificate program-Risk Management at University of Calgary. He was a recipient of the Gerry Roxas Leadership Award, the American Field Service (AFS) Scholarship grant, and the CALTEX scholarship grant where he specialized in Petroleum Refinery Maintenance. The author wants to share his knowledge and leave behind some legacy to all readers, most especially to his wife, children and lovely grandchildren, Eva and Mia.
This entry was posted in Analysis, Baseline Management, Business, Causes and effects, Construction Management, Integrated Schedule, Issues and Problems, Planning and Scheduling, Primavera Administration, Program Management, Program Schedule, Progress Measurement, Project Management, Risk Assessment and Treatment, rufran frago, Rufran's Blogs, Schedule Baseline, Threats, Uncategorized, Variance Analysis and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

One Response to Ten Cardinal Rules to Good Schedule BL Management

  1. Pingback: Project Schedule Baseline Top Ten Prerequisites | Your World, Our Risk Universe

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s