The project shall develop the schedule according to the level of details prescribed in each Gate or Phase. Each Gate shall have a schedule baseline. Approval of the schedule baseline is necessary before the project crosses each Gate until the execution Gate.
It is critical to analyze trends and variances using data derived from the schedule on regular basis. The project quantifies the deviations from the target. Threats and opportunities become clearer and decision-making becomes easier.
Quest for a Reliable Project Baseline
We all want a reliable project baseline for all established processes to work well. The official schedule baseline gives the project a good line of sight to what it wants. Having a good baseline increases the company’s strategic advantage and makes it more successful compared to those who have not.
Projects can only perform schedule forecasts by comparing progress against the official schedule baseline and computing time estimate to complete (ETC); e.g. schedule variance (SV) and Schedule Performance Index (SPI). These are important measures of change.
It is a good reminder to all: If there is change, there is risk.
You have probably seen it before. The project schedule that is supposed to manage time becomes the victim of time.
The PC Manager barking his order with a glint of a measured warning in his eyes. He wanted the baseline schedule completed right away.
“The schedule must be good enough by now. We need to submit the baseline today before 12pm! Senior Leaders are meeting tomorrow. Fail to submit now and we all would be looking for another job next month.”
The project team must understand that the quality requirement of the project depends on good inputs (data/information maturity). Maturity spells identification, clarity, correct level of details and completeness. Maturity of work components should spell quality.
The quality of the schedule baseline directly relates to data maturity. It is a measure as to when certain information are acceptably ready. Reliability of work data increases through time.
Source: Frago, R. (2015).Plan to Schedule, Schedule to Plan (Draft Manuscript). ISBN 978-0-9947608-2-1 (Canada)
I will attempt to share with you my top ten prerequisites to establishing the project schedule baseline. The prerequisites are what I conceived to be the most essential inputs there are in order to come up with the most reliable project baseline.
BL = Baseline
The acronym BL in this article points to the Official Project Schedule Baseline and/or the individual Gate Baselines unless specifically described as something else. Note that project baseline, official baseline, official schedule baseline, and gate baseline are used interchangeably.
SBL = Schedule Baseline
EDS = Engineering Design Specifications
FEED = Front End Engineering Design
SRA = Schedule Risk Analysis (also called SQRA)
SQRA = Schedule Quantitative Risk Analysis
The term “User/s” in this article is the person using the Primavera scheduling tool.
Project Management (Primavera 6.1 SP1, 6.2, 6.7 SP1, 6.7 SP2, SP5 and higher)
This is a static copy of the project schedule target, created once the target is agreed-to by all the stakeholders. This should be under version control (TheP6Pro, 2014).
Changing the approved project baseline is a No-No.
If an approved baseline needs changing due to error or a valid agreement, the changes shall go through a management of change process. However, the re-baseline will be another version (a modified version) of the previous. It means that the previous baseline stays as-is. It must not change.
The replacement baseline is a version distinct and unique from the existing one. It stands on its own merit.
The project baseline field holds the official schedule baseline. If in Gate 2, the data entry field holds the official baseline for Gate 2. If in Gate 3, the project baseline is the one approved for Gate 3.
BL Project prefixed fields display data based on the baseline snapshot assigned in the Project Baseline field.
Primary, Secondary, Tertiary (ad-hoc Baselines)
These are User Baselines. These are ad-hoc snapshots of the project schedule to extract periodic variances.
What is Primary, Secondary, and Tertiary depends upon the purpose of the analysis. It is essential in performance, forecasting, trending and productivity assessment.
There is no fixed and rigid rule to their use. The project organization shall include them in their basis of schedule.
The User must first create a baseline and then assign it to one of the three User Baseline options; i.e. Primary, Secondary, or Tertiary.
Figure 1 – Creating a Baseline and Assigning its Type
If the User wants to assign a Primary Baseline, the BL1 prefixed columns in the table area will contain dates pertaining to that baseline. This assignment is set in the Assign Baseline dialog window. The same steps hold true for assigning Secondary and Tertiary Baselines.
BL2 and BL3 prefixed fields will display data from whatever assigned baseline snapshot is available in the Secondary and Tertiary fields of the Assign Baselines dialog.
If the User does not assign a baseline, Primavera automatically uses the current schedule itself as the assigned baseline. The Baseline Name takes the name of the project schedule and add to it hyphen B1 if it is the first baseline created. The Data Date and the Last Update Date are automatically recorded (Figure 1); e.g. 02-Oct-09 and 02-May-16. No User can manually change these dates.
At the start, the current control schedule is equal to the original baseline.
As such, there would be zero variances on all assessed values. The first variance will occur only after making an update to the current schedule.
Figure 2 – Assigning a Baseline to the Current Schedule
TOP TEN BASELINE PREREQUISITES
1. The baseline schedule shall represent the most likely schedule
The baseline schedule is the most-likely schedule. It does not have built-in float, buffer duration, or/and dummy activities. It is neither optimistic nor pessimistic (tight or lax).
It has full complement of qualified resources, with no embedded risk or any built-in schedule contingency.
2. An official project BL Schedule shall be a result of Interactive Planning
All baselines set from Gate 2 onward shall be the result of an interactive planning session.
3. Schedule scope shall equal plan scope
The plan scope shall be the same scope reflected in the baseline schedule that follows. Planned scope and the scheduled scope must be in alignment. A schedule cannot have more than the scope in the plan. Otherwise, the project faces a problem (Frago, Schedule Baseline Dilemma Part 1, 2015).
4. Schedule BL shall use critical path method
The baseline schedule is the result of the critical path method of scheduling. Schedule has sound logic and does not represent a checklist of activities.
5. BL shall be of good schedule quality
It is important for the schedule baseline to pass the required minimum schedule quality required by the Client. A good schedule baseline is a mandatory requirement.
6. SRA shall be conducted before approving the baseline (Gate 2 onward)
Subject all proposed project schedule baselines from G2 DBM onward to SQRA.
7. Official project baselines shall have important stakeholder’s prior buy-in and sign-off
Official schedule baseline must be approved/signed-off by all important and influential stakeholders. These includes the Project Baseline, the Gate Baselines (G1 onward) and the Official Schedule Baseline.
Ad-hoc baselines are what we can call periodic baselines. They are snapshot in time of the current schedule at a given data date. They represent the picture of the regular historical update per data date move of the current schedule.
8. All schedule baselines shall reflect the execution plan
The schedule baseline reflects the execution plan based on the Gate’s available information. If there are still missing information, all assumptions must be documented in the basis of schedule.
9. An approved baseline shall have a covering basis of schedule
The basis of schedule (BOS) and methodologies is a plan that serves as the main source of information in building the schedule. It takes relevant information from all the other project execution documents, such as the construction execution plan, procurement management plan, modularization plan, contracting plan, risk management plan, and several others.
The project must approve the BOS first before the BL schedule. However, the gap between approvals can be close together. They can end up being approved at the same time. This happens when the two are developed closely in parallel with each other.
10. The baseline schedule shall align with the baseline estimate
If the baseline schedule is already resource loaded, it shall align with the frozen estimate (Frago, Risk-based Management in the World of Threats and Opportunities, 2015)
This requirement is especially true for execution baseline, which is typically the requirement at Gate 3 or EDS/FEED Stage.
Rufran C. Frago – Author (Rev. 0, 03-May-16)
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
- Your World, Our Risk Universe
- Rufran Frago in the Global Risk Community Site
- Earthquakes, Super Typhoons and Fundamentals of RBM
- and more…