Project Baseline Schedule Review – projectcubicle

Baseline Schedule Review - A Complete Guide-min

Project Baseline Schedule Review – A Complete Guide

In my profession being a Consultant, Project Controls Specialist, Planner, Scheduler I was often tasked to review a schedule. Review of schedules are varied from the client (owner, main contractor or sub-contractor) and type of schedule to be reviewed. Depending on the complexity and details of the schedule, schedule review can be measured against quality, health, structure, risk and etc… In this blog post, we will focus on the project baseline schedule review. We will also give you a project baseline schedule review checklist including many elements such as contract compliances, activities, calendars, Work Breakdown Structure codes, critical paths and so on.

Many companies had their own guidelines on the Project Baseline Schedule Review process that are already in place where the readers should be aware and shall comply with their company procedures. This blog post shall be used only as a reference and guidance for the enrichment of knowledge on the topic.

Purpose of Baseline Schedule Review

The main purpose of the project baseline schedule review is to analyse the schedule health, structure, critical path and compliance with the work under the contract (WUC) or other terminology; scope of work (SOW) prior to acceptance and approval of Baseline Schedule.

The approved schedule is often referred to as the baseline schedule that will be used for comparing the actual achieved dates as well as measuring progress. The baseline schedule is a model of project execution plan reflecting the intent to reach project completion while integrating the various contractual requirements.

The accepted project baseline schedule will be the basis of measuring actual progress and monitoring performance throughout
the life cycle of the project from initiation to closeout unless otherwise a new approved revised baseline has been introduced.

Project baseline schedule reviews should preferably take place prior to the start of execution of the work, or as soon after, to remain relevant and applicable. Even if performed later, all knowledge of events that transpired after the start of the work should be disregarded. The guidance presented here is not applicable to revised baseline plans or schedule update reviews.

The focus of a baseline review is intended to address the evaluation of the critical path method (CPM) of the original baseline schedules as well as the overall quality and completeness of the original project schedule and plan. It is not an assessment of current progress or subsequent project schedule changes.

Project Baseline Schedule Review is performed by analysing the entire schedule and determining if the schedule reflects a realistic, complete and workable plan in accordance with contractual requirements to achieve successful project completion. The schedule should meet the minimum requirement of industry-standard CPM principles as stated in the contract unless if the schedule specification allows or prohibits a specific CPM practice, then that practice is allowed or prohibited (as the case may be) regardless of other considerations.

Project Baseline Schedule Evaluation Criteria

The project baseline schedule should be evaluated using the following criteria:

  • Contract requirements and specifications including reporting format
  • Basis of Schedule (contents and consistency with the schedule)
  • Contractor methodology and project execution plan
  • Resources – (direct labour, indirect labour, materials, equipment) – if stipulated in the contract
  • Cost Resources – (if stated in the contract) weighting for measuring progress
  • Professional scheduling practices and guidelines generally accepted for use by professional scheduling practitioners.
  • Important items that should be considered in the project baseline schedule and shall be clearly defined in the Basis of Schedule are:
  • Critical procurement and long lead time activities
  • Principal deliverables
  • Activity Duration and buffers included on the schedule
  • Concurrent activities of similar work that exceed daily planned crew resources
  • Predecessor activities unrelated to successor activities.
  • Project Milestone (Key Milestone, Interface Milestone, Contract Milestone)
  • Area access restrictions
  • Coordination with other projects
  • Clear and identifiable critical path
  • Compliance with contractual requirements

Project Baseline Schedule Review Checklist

As a guide, below are my suggested project Baseline Schedule Review Checklist that can be used. Please note that this is only a guide, and some items might not be applicable in the contract and or redundant to the requirements.

Contract Compliences

1. Proper identification of the Schedule – Does the schedule contains the proper company name, project titles and version of the schedule?

2. Submittal Contents – Check to make sure that the submission has included all the required components such as:

  • Basis of Schedule (BOS)/ Narrative
  • Native file of the schedule
  • PDF’s printout of the schedule
  •  Tabular and graphical bar chart reports, S-Curves, etc. reporting requirement

3. Contract/ Schedule completion date – Is this date meet the specified contract completion date in the contract?

4. Time/seasonal Restrictions – Do the activity early and late dates indicate the time/seasonal restrictions/requirements in the contract?

5. Substantial Completion Date – Does the schedule shows the substantial completion, practical completion or whichever term is used in the contract, and what activities are necessary to achieve for such completion.

6. Regulatory/ Permit requirement – Is the contractor responsible for complying with any regulatory requirements or permits as specified in the contract? If so, are those requirements shown in the schedule?

7. Milestone – Are all contractual completion and interim milestones been represented in the schedule correctly and as zero duration milestone activities? Major phases/stages completions should all have milestones.

8. Contract Access Restrictions – Is the contract indicates access restrictions such as environmental, health and safety, authorisations to start work/gain access in certain areas, or any other related constraints and are they properly reflected in the schedule?

9. Submission Timing – When was this baseline received and when was the submission required by the specification specified in the contract?

10. Work Breakdown Structure – Does the WBS conforms with the contract requirements? Does the phasing/ staging reflect the WBS stated in the contract?

General Check

1. Calculate the Schedule – Calculate or run the schedule using the appropriate software tools and compare it to the contractor’s version to see if anything changes. Is the CPM schedule date still intact? Are the early and late calculated dates present for each activity?

2. Data Date – Is this date on or before the Project Start?

3. Out-of-sequence CPM calculation rules – is the schedule using retained logic or progress override. The scheduling method should be set to accommodate out-of sequence progress using retained logic.

4. Schedule Errors – Check the schedule log report if there are any anomalies, warnings and errors that need to address in the schedule.

5. Imposed Finish Date – Is the schedule have imposed date or a “must finish” date?

6. Total tasks or activities – Are the number of activities represents the level of schedule specified in the contract? Are the activities reflective of the full work under the contract (WUC) or the scope of work (SOW) stated in the contract?

7. Insufficient Details – Check activities have enough detail and the number of activities that have a duration longer than 10% of the total duration of the project. This number should not exceed 5%.

8. Milestone Ratio – Calculate the ratio of Milestones to Normal Activities. This is a powerful metric that shows the number of deliverables against the number of activities required to achieve these deliverables. If the ratio is less than 1:20, then the plan needs to be further fleshed out to reflect more detail in the work (activities).

Deliverables, Submissions and Procurement

1. Contractor Design Submission – Is there any design work that is the responsibility of the contractor and if so, is that design work sufficiently detailed in the schedule? Are all deliverables listed on the contract specification or SDRL are present or are they required in the schedule?

2. Submittal Duration – Do the submittal review and approval activity durations conforms with the timing specified in the contract?

3. Submittal Contents – Are all submittals required by the contracts present on the schedule? If the submittals are defined in a one-line item, the details shall be clearly specified in the Basis of Schedule and its gates/ rules of credits reflecting the stages of each submittal for monitoring the progress.

4. Procurement and Long Lead Items – Check to make sure there is adequate float in any complex procurement activities to accommodate possible multiple submittal iterations. Is the duration for long-lead items clearly defined on the Basis of the Schedule?

5. Fabrication Activities – How are fabrication activities detailed in the schedule? Is the methodology and execution approach for all fabrication activities was detailed and clearly discussed in the Basis of Schedule to provide a clear understanding of the contractor’s intent and what to expect in the schedule? Is the contractor going to fabricate items in advance of when they are needed and if so, how is the storage of those items going to be managed? Is the contractor going to fabricate items just in advance of when they are needed so that storage will not be necessary? Does the schedule properly reflect the contractors chosen strategy and how they will proceed with fabrication?

6. Fabrication Activity Detail – Are there any large, time-consuming fabrication activities including long-lead equipment that needs expanding into details to manage and monitor the progress?

Activity Durations

1. General Check – The schedule should reflect how long each activity will take to execute. In determining the duration of each activity, the same rationale, data, and assumptions used shall be defined in the Basis of Schedule, and the same tools and technique used for cost estimating. Furthermore, these durations should be as short as possible and have specific start and end dates.

2. High Duration – Check if the duration exceeds two reporting cycles, with the exemption of long lead item, and whether it is clearly discussed in the Basis of Schedule. Durations longer than 44 days or 2 months shall not exceed 5%.

3. Zero duration activities – Ensure that there are no zero duration task activities other than milestone.

4. Wet weather allowances/buffer – Wet weather or any schedule buffer shall be clearly detailed on the basis of schedule (BOS); if it is included on the activity duration/built-in on the rates or separate buffer activity and how it is being managed through the life cycle of the project.

Activity Analysis

1. Activity Distribution Histogram – Confirm that the level of detail in the schedule is roughly equally distributed from start to finish of the project.

2. Mechanically incorrect dates – Are there any activities that have missing early start and finish dates. Finish dates should not be earlier than start dates (a situation which generates a calculation of negative float).

3. Actual Dates – Check that the schedule does not contain actual dates.

4. Proper activity types – Test if activity durations do not change automatically depending upon resource assignment or other activity’s durations.

5. Proper measurement of activity completion – Check and validate the settings for activity percent complete complies with specification (duration, unit, physical, etc…)

6. Missing activity description – Confirm that all activities are present and described are appropriate and reasonable.

7. Duplicate descriptions activity – Ensure all activities have unique identification and description.

Activity Codes

1. Activity Codes Structure – Confirm that the activity coding is compliant with the scheduling specification and follows scheduling best practice. Ensure the schedule contains, at a minimum, activity codes fields designating location, phase, discipline and responsibility.

2. Activity Codes Assignment – Check if the activity codes are properly assigned to activities and coded in accordance with the contract requirements.

3. Duplicate activity codes definitions – Examine the activity codes dictionary for duplicate or near-duplicate descriptions. Are these activity codes definitions allowed in the contract specifications?

4. Blank activity codes values – Are there blank values for activity codes for any of the activities and if there is, is this permitted?

5. Report levels and requirements – Are the activity codes meet the minimum report levels and reporting requirements specified in the contract?

Work Breakdown Structure (WBS) Codes

1. Missing Work Breakdown Structure definitions – Confirm that all Work Breakdown Structure levels are fully defined and not blank.

2. Duplicate Work Breakdown Structure names – Check the Work Breakdown Structure for duplicate WBS names. Ensure that Work Breakdown Structure name has unique identification such as areas, phase or stage and meaningful on the report.

3. Work Breakdown Structure assignments – Check if all Work Breakdown Structure had activities assigned and complied with the contract and reporting requirements.

4. Work Breakdown Structure definitions – The complete project scope should be captured using the approved project Work Breakdown Structure. Scheduled WBS hours, cost or unit’s distribution should be aligned with the estimate and Work Breakdown Structure dictionary elements shall be clearly discussed in the Basis of Schedule, including all constraints and assumptions made by the contractor. Work Breakdown Structure levels should be able to be used for summary progress reporting.


1. Calendar – Check schedule calendar structures and individual calendars. How many calendars are there in the schedule and what are the working days for each one of them? Check if the calendar represents the correct working time period for each phase/stage of the schedule (i.e.: design, procurement, fabrication, installation/ construction, commission and testing) and complies with the working time period stated in the contract.

2. Holidays/non-working days – Check to make sure that planned holidays are reflected in the schedule, including breaks and non-working periods.

3. Activity Calendar Assignments – Is each activity assigned to the correct calendar? Is the predecessor of normal task/activity have the same calendar assignment?

Logic and Sequencing

1. Logic – Examine and confirm that the logical relationships of the schedule conform to CPM network principles. Best practice encourages that the schedule should only have a single activity without a predecessor/defined as start milestone (representing project start) and a single activity without a successor/ defined as finish milestone (representing project completion). All other activities should have both a predecessor activity and a successor activity. Confirm that CPM network is compliant with the scheduling specifications and in accordance with scheduling best practice.

2. Summary activities – Check for proper coding of summary activities, such as hammocks and level of effort. Other, non-supported relationships may corrupt the purpose of the summary activity and should be reviewed carefully. Check if these types of activities are allowed in the contract.

3. Workable sequence of activities – Example: There is sufficient time allotted between the submittal activity, the review and approval activity that logically follows. The review/approval activity should have a fabrication/delivery successor followed by the actual installation successors.

4. Missing Logics in Milestone – Check the number of activities that are missing predecessor, successor, or both. This number should not exceed 5%.

5. Missing Predecessors – Check the number of normal activities and milestones that have a missing predecessor.

6. Missing Successors – Check the number of normal activities and milestones that have a missing successor.

7. Open Ends Logic – Check that activities with Start-to- Start (SS) relationships have been paired with a Finish-to Finish relationship to close out completion of the activity. This must occur to avoid excessive float.


1. Negative Float – Check to see if there is any negative float. Negative float is not supported by industry-standard best practice and should be avoided.

2. High Float or Excessive Float – Check large float values. Does it make sense that the activities with large amounts of float are sensible to have that float? Activities that seem to have unusually float values should be checked to see if there is a broken network or missing link along whichever path they are on. The total float should not exceed 2 reporting cycles or 2 months and or 10% of the total project durations.

Lag and Lead

1. Lead or Negative Lag – Check if negative lag is present in the schedule. This technique is not supported by industry standards and shall be avoided unless there is a valid reason for it. SS and FF relationships should have zero or positive lags only.

2. FS relationship should not have positive lags (Values greater than zero) – This restriction is since the calendar used for the relationship is typically not individually adjustable and therefore is often inappropriate. In addition, typically not possible to status or review the status of an ongoing positive lag and is recommended to be replaced with activity instead of a lag for this purpose.

3. Large lags would be better coded as separate activities – Check for the huge lags and make sure that there is an acceptable reason behind them. Lags cannot be used to update the progress and indicate whether they were behind or ahead. For lags of long duration (such as the delivery of a major piece of equipment), it would be better practice to create an activity that would show up on reports with its progress every update. Generally, lag values of more than 15 workdays should be defined as schedule activities for better visibility, justification and progress monitoring.

4. Lags that do not overlap the activity – Lags that do not overlap either the predecessor or successor activity are unusual. Lags are used to describe linked activities that are staggered and/or partially overlap in time.

5. Lags longer than the activity’s duration – Lags are typically used to allow related activities to overlap in time. When the lag is larger than the activity duration, this overlaps condition no longer exists and the reason for using the SS or FF relationship disappears.

6. Any lag other than zero – Besides just ‘odd’ lags, most schedulers are interested in reviewing any relationship that uses a lag other than zero. Each instance of this should be reviewed to determine the reason why they exist.


1. Imposed finish date – Ensure that a must finish date on the entire project has not been set. Check if a constraint to the final activity was assigned to determine the contract performance period.

2. Free float constraints (as late as possible constraints) – Review and verify the reasonableness of all such “zero float constraint” usage in the Schedule. Using a zero free float constraint for delivery activities can pose a project risk as any delay in delivery will then delay successor work activities.

3. Expected finish constraints – Make sure that expected finishes do not exist in the schedule without justifications. The use of expected finish constraints may indicate an attempt to artificially inflate the duration of an activity to use all of the available time.

4. Mandatory constraints – Check that mandatory start and finish constraint does not exist in the Schedule. Mandatory start and finish constraints completely override network logic and do not allow for proper float calculations.

5. Start On constraint – Check the start constraint if exist and have a valid reason for it or is allowed in the contract. Start on constraints control the start of an activity in both the forward and backward direction. Unlike mandatory constraints, they will still obey CPM logical rules and not start activities prior to all predecessors being satisfied.

6. Contractual constraints – Constraints should be used to reflect contractual requirements and not used just to make the early start date of activity equal to the planned start. A listing and explanation for the use of all non-contractual constraints should be included in the Basis of Schedule with all assumptions and intended purposes.

Critical Path

The Critical Path(s) – the longest path through the network, shall be clearly indicated with the use of Finish- to- Start (FS) logic, linking all activities through each project phase (such as approvals, engineering, procurement, contracts, off-site assembly, site construction, shutdowns/tie-ins and commissioning) reflected in the scope of the contract and in compliance with the CPM method Schedule Standard Practice. The critical paths shall be described in the Basis of Schedule.

1. Critical Path Definition – Does the schedule define the critical path as:

  • Activity with Float less than X or
  • Longest path

2. Critical Path continuity – Check if the critical path is genuine and not constraint-driven. Constraints may affect float and create false critical path(s). The technique used to assess the critical path is by adding durations to critical activities (say 100 days) then calculating the schedule. If the result of the new completion date is the same as the added duration, then the critical path is genuine, otherwise, if there is a variance in the result then the activities were forced to be critical.

3. Percent Criticality – Check to see what percentage of activities are critical and near critical (say float < 2 weeks) to gauge how tight the schedule is. Depending on the type of contract, the industry standard for manageable critical activities is between 30% to 40%. Anything above this percentage shall be described in the Basis of Schedule, including an explanation of how it will be managed.

4. Critical Path Reasonableness – Check the critical path and near-critical paths or longest path and near longest path. What work is on these paths, and does it make sense given what the most difficult and time-consuming parts of the project are?

5. Multiple, simultaneous near-critical path – Under normal circumstances, CPM networks should not have multiple critical paths occurring at the same time without thorough justification. A detailed review shall be conducted on these simultaneous activities and possible recommendations to re-adjust durations, logic, and lead times to
avoid artificially created multiple paths.


1. General Checks – The schedule should realistically reflect what resources (i.e., labor, material, and overhead) are needed to do the work, whether all required resources will be available when they are needed, and whether any funding or time constraints exist. Check what are contractual obligations and reporting requirements such as:

  • Direct Labour and In-Direct labour – (Man-Hour resource) defined labour resource man-hours provide phase/ stage or construction histogram, productivity analysis and Earned Value including 3-Part Curve or whatever is stated in the contract. Is the budgeted hour equal to contract hours? Is the manning histogram matched with the submitted manning requirements?
  • Cost Resources – assigned for cost distribution across all activities using approved estimate/ contract value or activity approved/ agreed weightings to measure and monitor progress including Earned Value, S-Curve and other reporting requirements specified in the contract.

2. Resource Level Schedule – Analyse the resource loading of the schedule. Check that the resource of the schedule was not automatically resource leveled the system used.

3. Resources – Number of activities that are carrying resources. Includes normal activities and LOEs that are planned.

4. Missing Resources – Number of activities that are not carrying resources. Useful in pinpointing activities that have not been resource-loaded. Includes normal activities and LOEs that are planned.

5. Resource congestion – Describe all congestion issues pertaining to resources influencing the schedule and make sure it was addressed on the basis of the schedule.

6. Milestone and Summaries with Resources – Number of milestones and summary tasks that are improperly carrying resources. Includes milestones and summaries that are planned. These should not be allowed in the schedule.

Related posts

3 thoughts on “Project Baseline Schedule Review – projectcubicle”

  1. 2. Resource Level Schedule – Analyse the resource loading of the schedule. Check that the resource of the schedule was not automatically resource levelled the system used.

    Please explain what did you mean by this advise? Do you suggest to ignore resource leveling?

    • Hi Vladimir,
      Thank you for your query. For clarification, some project management software (ex: P6) has an option of automatically levelled the resources when running the schedule (schedule calculation). Having this option selected or tick, it overrides the original intention of the CPM, or the schedule intended purposes. This option is valid if clearly discussed or included in the “Basis of Schedule” so that the reviewer is aware why the task pushes out to later date with or without successor driving the activities.
      Hope this clarify you query. Thank you

      • Thank you Rodel.
        I agree that resource constraints and resource leveling requirements must be clearly discussed and included in the “Basis of Schedule”. But if resource constraints exist project baseline must be leveled and the reviewer must be informed.
        Unfortunately most scheduling programs including P6 calculate wrong floats in resource constrained schedules and as the result show wrong Resource Critical Path. So schedule analysis become much more complicated when the software does not show right floats and resource dependencies.
        But usually project baselines are created ignoring resource constraints, risks and uncertainty. This is one of the reasons why many projects are late.


Leave a Comment