additional guidelines pmp rev 01

AECOM Additional Guidelines Tatweer Buildings Company

Revision 0 - 17 Feb 2015

Riyadh School Development Program (RSDP) Riyadh Region, R – 111

Contractor’s Schedule Guidelines

Rev – 0


Revision 0 - 17 Feb 2015

Table of Contents

Executive Summary ......................................................................................... i 1 .........................................................................................................................PROGRAMMING .......................................................................................................................... ii 1.1 GENERAL ...................................................................................................................................................... ii 1.2 FORMAT ........................................................................................................................................................ 3

1.2.1 Software .................................................................................................................................................. 3 1.2.2 Critical Path Method (CPM) .................................................................................................................... 3 1.2.3 Program Components ............................................................................................................................. 3 1.2.4 Activity Description and Set-up ............................................................................................................... 4 1.2.5 Duration ................................................................................................................................................... 4 1.2.6 Imposed dates ......................................................................................................................................... 4 1.2.7 Numbering ............................................................................................................................................... 4 1.2.8 Activity Riding .......................................................................................................................................... 4 1.2.9 Program Layout and Sequence of Activities ............................................................................................ 4 1.2.10 Work Breakdown Structure (WBS) ...................................................................................................... 4 1.2.11 Activity Coding ..................................................................................................................................... 6 1.2.12 Activity Numbering ............................................................................................................................... 6 1.2.13 Resource and Cost Loading ................................................................................................................ 6 1.2.14 Calendars ............................................................................................................................................. 6 1.2.15 Resource Loading ................................................................................................................................ 7 1.2.16 Cost Loading ........................................................................................................................................ 7 1.2.17 Format .................................................................................................................................................. 7

1.3 PROGRAMME SUBMISSIONS ..................................................................................................................... 7 1.3.1 Preliminary Program ................................................................................................................................ 7 1.3.2 Narrative .................................................................................................................................................. 7 1.3.3 Baseline Program .................................................................................................................................... 8 1.3.4 Progress Program ................................................................................................................................... 9 1.3.5 Look Ahead Program ............................................................................................................................ 10 1.3.6 Recovery Program ................................................................................................................................ 10 1.3.7 Extension of Time Program ................................................................................................................... 10 1.3.8 Variation Requests ................................................................................................................................ 11

1.4 REVISION AND UPDATE ............................................................................................................................ 11 1.5 REVIEW ....................................................................................................................................................... 11

1.5.1 General .................................................................................................................................................. 11 1.5.2 Review Comments ................................................................................................................................ 12 1.5.3 1.5.3 Supporting Document ................................................................................................................... 12


Revision 0 - 17 Feb 2015 Page 1 of 16

Executive Summary

The purpose of the Contractor Guidelines is to establish the critical processes required to develop and maintain an integrated logic driven Program Master Schedule (PMS) baseline and working Critical Path Method (CPM) based schedule. The PMS provides the basis for communicating, analyzing and executing the Program Plan. The updating of the schedule will allow for measuring, analyzing and reporting schedule i.e. Variances and trends performance. The processes are developed to ensure data integrity and integrations within the Enterprise Program Management System (EPMS) applications and other sources.

This document is to define the development of the PMS from the Work Breakdown Structure (WBS), Project Initiation, Planning and Implementation stages of the assets. The processes for Baseline Schedule Management and Program Master Schedule.

Abbreviation

Description TBC

Tatweer Building Company

P&D

Planning and Development

CPM

Critical Path Method

PMS

Program Master Schedule

WBS

Work Breakdown Structure

CM Construction Manager

PC Projects Control

GC General Contractor

CS Consultant Supervision

TIA Time Impact Analysis

V.O Variation Order

CL Claim

COD Cut off Date

COB Cut off Business

EVM Earned Value Management



1 PROGRAMMING

1.1 GENERAL

The Programs (and Program documents) described herein are for the following purposes:

To define the GC’s (General Contractor) baseline plan (including logic and use of man-hours identified by discipline sub-sections) for completing the works.

To report progress in completion of the works and support Earned Value Management and invoicing.

To evaluate Contractor’s progress payments due to the GC through the usage of Earned Value Management(EVM).

To evaluate any changes to the GC’s baseline plan and subsequent updated plans including recovery plans to meet original baseline dates.

To identify all milestones that represent major deliverables by the GC.

To assess the impact of proposed variations.

To identify and coordinate all interfaces with other GCs, and minimize the potential for delays caused by or to other GCs.

To identify the responsibilities activities of all parties for activities in the Program.

To manage the execution of the work in a manner that allows all deliveries in accordance with Contract requirements.

To serve as a communication tool between the Employer and the CS, the CS and the GC and the GC and its sub-GCs.

The GC is encouraged to use the Program to establish an understanding with all parties of the assumptions regarding the works and constraints and opportunities that are possible within the plan. As the works progress, the GC and the CS (Consultant Supervision) will use the Program documents to assess impacts and to formulate the best methods to complete the works on, or ahead of the contractual completion dates. The Program documents will also be used by the CS in the evaluation of the GC’s monthly progress payment requests through the use of Earned Value Management including submittal to the Employer for final review and approval.

At anytime throughout the course of the works, the CS reserves the right to or additional activities (or recovery Programs) to be added to the Program to clearly define the GC’s plan and intentions regarding the execution of the works. In each instance, such activities or changes shall be made by the GC at no cost or delay to the Employer.

The services provided by the CS, the existence of Programs, networks or any other charts or services prepared or performed by the CS, shall in no way relieve the GC of the responsibility for complying with all of the requirements of the Contract, including, but not limited to, the responsibility for completing the works within the period for completion of the works and the responsibility of planning, scheduling and coordinating the works, including work by third parties. The GC is required to comply with all Program requirements specified herein and any modifications which the CS determines to be reasonable and necessary during the contract execution, without any time or cost impact to the Employer.

RSDP Program Management Plan


The Programs (and Program documents) shall be formally submitted to the CS (Consultant Supervision) in a timely manner as required by this section, the general conditions and the supplementary/particular conditions. Failure to submit the Program and Program documents on-time and in an acceptable format, with the required content to the CS, may result in withholding of payments or other remedies.

The GC shall have seven days to prepare program and re-submittals. All Programs shall be submitted in the following manner: five color paper copies and one electronic copy on CD/DVD of each Program in Oracle Primavera P6 Professional Project Management tool (.xer), Primavera Layout Files (.plf) and Adobe Acrobat (.pdf) formats and the narrative in Microsoft Word (.doc) and Adobe Acrobat (.pdf) formats. Courtesy copies delivered via-email will be encouraged but will not replace the formal transmittal of the submittal.

1.2 FORMAT

1.2.1 Software

Unless otherwise specified, all Programs shall be produced and submitted utilizing the Windows-based Oracle Primavera P6 Project Management tool. All submissions shall be in the version of Primavera directed by the Employer (currently P6 Version 8.2, although the GC may be required to migrate to a newer version during the execution of the works).

1.2.2 Critical Path Method (CPM)

All Programs shall comply the Critical Path Method (CPM) using retained logic for the planning, scheduling and reporting of the work to be performed under this Contract Agreement. The CPM schedule will be an activity driven schedule not driven by resources. The calculation of lags will be on Actual Dates. The Duration Type will be Fixed Duration & Units / Fixed Duration & Units/Time.

1.2.3 Program Components

The preliminary, baseline and progress Programs shall include, but not be limited to:

1. Narrative Summary

• Introduction

• Explanatory Notes

• Acronyms / Abbreviations

• Grouping Strategy

• Scheduling Methodology

• Milestone Details

2. All critical, milestone and completion dates defined in the Contract Agreement, including dates of contract award, Notice To Commence (NTC) or Site Handover, overall completion and completion of each phase.

3. Critical procurement and submittal activities.

4. Others’ activities that interface with the GC’s works, including work by the Employer and Employer’s consultants, and other similar activities.

5. All required design reviews.



1.2.4 Activity Description and Set-up

The description of work by activity and activity coding shall contain the specific type of work(s) to be done and the physical area of the work(s) to which the activity pertains. Activity boundaries shall be easily measurable and descriptions shall be clear and concise. Activity descriptions shall not be prefaced with “Begin” or “Complete.” The beginning and end of each activity shall be readily verifiable and physical progress shall be quantifiable.

1.2.5 Duration

With the exception of Level of Effort (LOE) and Long Lead Material Items activities, activity durations over 21 working days shall be kept to a minimum. Exceptions to this shall be permitted only if accepted in writing by the CS. The duration of activities shall be in working days.

1.2.6 Imposed dates

Imposed completion dates for events other than milestone dates or completion dates are generally not permitted and shall be agreed upon with the CS. Artificial constraints (imposed start dates, finish dates and in general any other constraint permitted by the software) are generally not permitted except for use in TBC interface dates and similar. TBC interface dates shall have an early start/finish and late start/finish range. All TBC dates shall be related to the GC’s works with predecessor and successor logic such that float is correctly calculated on TBC interface dates.

1.2.7 Numbering

Activity numbering shall be sequenced to allow inclusion of new activities between existing activities while still maintaining a similarity of numbering for like activities. Numbering by area, level, etc., is encouraged to assist in analysis. The numbering may be alpha-numeric to allow easier identification of areas, etc. Renumbering or renaming of existing activities is expressly not allowed.

1.2.8 Activity Riding

Activities shall not “ride” the data date. Where activities have failed to commence and are not logically linked to any uncompleted activities a forecast start date shall be applied and where such a forecast date is beyond the next reporting period, an explanation should be provided in the accompanying narrative. Similarly “compression” of remaining or un-started activities is also not permitted unless approved by the CS.

1.2.9 Program Layout and Sequence of Activities

The Program Layout shall be consistent with the project conditions and milestones set forth in the Contract Documents. Works required to complete each milestone shall be easily identifiable in all GC’s Programs. In general, it is desired to have the works needed to meet the Contract Agreement milestones be detailed activities that summarize, or roll-up to provide plan and status information reported for the milestone.

The summarized overall Program shall allow reporting of physical progress, revenue and manpower loading for the entire works. The CS’s intent is to use the GC’s Program for milestones to summarize activities in the TBC’s Master Program (Capability Building) for all projects.

1.2.10 Work Breakdown Structure (WBS)

The WBS is a program / project management tool used to identify a program / project’s discrete work elements and collate them into an organized framework to support the management and execution of work and define overall scope.

The WBS for the Tatweer Building Project (TBC was developed in a format to support three primary objectives:

• Managing the execution of program works associated with the development of the School Development programs as TBC expands its portfolio.



• Developing a framework for an effective and integrated project controls solution including schedule, cost, for contractor BOQ/ needs Pricing to be verified, earned value, risk, safety, and quality in order to measure project / contract performance.

• Managing the full life cycle of an asset from project inception through decommissioning/ removal.

To support the three primary objectives as noted above, an asset-based WBS was developed and adopted which also allows performance measurement and capitalization of all project / asset costs over the entire lifecycle of the project / asset.

Additionally, a fully developed WBS methodology / structure forms the foundation of project delivery and asset management in a consistent and uniform manner which can be leveraged to support TBC from an organizational stand point.

WBS codes and contract numbering are two distinct systems. The WBS codes have been generated on the basis of an asset-based approach. Contract numbers will be provided for contracts that make up the level of effort in order to deliver the project / asset.

There may be several contracts assigned to one project / asset; as such, the correlation between WBS code and contract numbering is no longer applicable.

Planning & Development (P&D) Program Controls shall maintain the controlled master copy of the WBS at all times, and shall be responsible to track, report, analyze, and make recommendations against program/ project data against the WBS.

The WBS forms the backbone of all program/ project data and is required for integrated reporting; as such, strict oversight and control shall be maintained and enforced by P&D Program Controls. This policy has been developed in conjunction with industry best practices and historical experience on the Tatweer Building Project CDP.

The Employer has developed the overall Program WBS and associated organization; to maintain the consistency for all projects related to TBC, the GC shall be required to organize the Preliminary Program, Baseline Program, and all other Programs consistent with this format in Oracle Primavera P6 Professional Project Management tool as provided in the Program WBS structure below. No deviation shall be accepted unless otherwise approved by the CS and the Employer.

The project level is Level IV, with the Construction Contract located within a Control Account at Level V. The GC shall be required to organize all Program, cost, and resource information within the Preliminary and Baseline Program in an elemental format utilizing the ASTM E 1557 – 09 Standard Classification for Building Elements and

LEVEL WORK BREAKDOWN STRUCTURE CODE

LEVEL I TBC TBC

LEVEL II Regions (R) TBC.XX

LEVEL III SD PROGRAM (School Development Program) TBC.XX.XX

LEVEL IV PROJECT (R111) TBC.XX.XX.XX

LEVEL V CONTRACT PACKAGES (CP06) TBC.XX.XX.XX.XX

LEVEL VI WORK PACKAGE / UNIFORMAT LEVEL II TBC.XX.XX.XX.XX.XXX

LEVEL VII TYPE - ELEMENT / UNIFORMAT LEVEL III TBC.XX.XX.XX.XX.XXX.XXX

LEVEL VIII Task(s), Task(s), Sub-Task(s), Activities

LEVEL IX (+) Sub-Task(s), Activities TBC.XX.XX.XX.XX.XXX.XXX.XXX.XXX….



Related Site work – UNIFORMAT II, with Levels VIII and lower assigned to the GC to organize by task, sub-task, and activity as required. Program WBS Level VI & VII shall be organized by Work Packages and Elements pursuant to the standards set forth in Section 2 “UNIFORMAT II Organization and Cost Estimating”; this shall take precedence relative to format and/or any discrepancies identified unless otherwise directed by the CS and Employer.

Each element, task, sub-task and/or activity in the Baseline Program shall have a WBS field encoded to it.

The GC’s is required to follow proposed WBS shall be submitted for review and approval by the CS. The GC shall receive written approval by the CS prior to modifying the approved WBS in any manner. Any modified WBS is subject to review and approval by the CS prior to implementation.

For purposes of consistency, the Employer will provide a blank .xer file (the backup file for P6 Version 8.2 or higher) to the GC; this blank file will contain predefined fields for the EPS/WBS structure, codes, calendars, etc. in the format required by the Employer for incorporation into the EPMS. No deviation from the format contained in the blank Program provided by the Employer will be accepted without prior consent from the Employer. The purpose of providing this blank Program template for the GC’s use is to provide consistency in the information format that will readily allow its incorporation into the EPMS. A draft blank .xer file will be distributed initially and a finalized version will be distributed at the time of award of the Contract.

1.2.11 Activity Coding

In addition to and separate from the WBS, each activity shall be coded to show, at a minimum:

1. The Phase of work (design, procurement, installation etc.). This coding structure will be provided in the blank Program template provided by the Employer.

2. The Party responsible for the work (GC, SubGC, CS, Employer, External Agency, etc.). This coding structure will be provided in the blank Program template provided by the Employer.

3. The physical location of the work (area, level, etc.). This coding structure will be provided in the blank Program template provided by the Employer.

4. Identification of interface and contractual milestones. This coding structure will be provided in the blank Program template provided by the Employer.

1.2.12 Activity Numbering

The GC shall propose, prior to the submission of the Baseline Program, an activity numbering scheme that helps identify activities by location and responsibility (including any sub-GC). A proposed structure will be included in the blank Program template provided by the Employer. Renumbering of existing activities will not be allowed.

1.2.13 Resource and Cost Loading

Each Activity shall be loaded with an Activity Budgeted Cost if applicable and resources to be confirmed at a later date with the CS. The GC shall submit his proposed resource and cost dictionaries. A proposed cost and resource dictionary will be provided in the blank Program template provided by the Employer.

1.2.14 Calendars

Make sure that all activities utilize the appropriate calendar. Only use pre-setup and approved global calendars. The calendars in the TBC schedules are as follows:

• Global Calender 7days/wk

• Saudi Arabia 6 days /wk

• Holidays Ramadan, Eid Al Adha and Saudi National day.



1.2.15 Resource Loading

The activities shall be resource loaded as agreed with the CS. Resources shall include manpower, equipment and material availability, as appropriate. Histograms of Resource requirements shall be produced with any limitations on resource availability indicated. Resource leveling of resources that are found to be over or under utilized as indicated in the produced Histograms shall be carried out at the request of the CS.

1.2.16 Cost Loading

The activities shall be Cost loaded as agreed with the CS. as appropriate. Histograms of Cost requirements shall be produced with any limitations on resource availability indicated. Resource leveling of resources that are found to be over or under utilized as indicated in the produced Histograms shall be carried out at the request of the CS.

1.2.17 Format

The baseline and progress Programs shall be submitted as color plotted time-scaled Gantt charts with sufficient calendar and spacing to allow activity description information and bars to be easily read as agreed with the CS. For each submitted Program, a color plotted time-scaled Gantt chart of just critical path activities shall be submitted. The provided layout, as described above, shall be used for all time-scaled logic diagram submittals throughout the duration of the project. The size shall be ISO A4 or A3 at the CS’s discretion.

The progress Program shall be submitted in an additional bar (Gantt) chart format that displays the previous month’s progress Program as a “target” Program for comparison use. The previous progress Program shall use the baseline Program as the “target” Program. The “target” bars shall be of smaller size, of different color and below the current Program’s bars. The page size shall be ISO A4 or A3 at the CS’s discretion.

The preliminary, baseline and progress Programs shall also be submitted in a bar (Gantt) chart format, as described above, but shall contain only critical path activities. In the event that the GC’s Program has more than 25% of the activities as critical path or near critical path, the GC shall submit an additional bar chart Program containing both the critical path and near critical path (as subsequently defined) activities.

1.3 PROGRAMME SUBMISSIONS

The following outlines the Programs and Program documents required to be submitted by the GC.

1.3.1 Preliminary Program

The Preliminary Program shall be submitted within 15 days after handing over of physical site execution of the Contract Agreement.

The Preliminary Program shall cover the entire duration of Contract; however, works to be executed during the first 15 days shall be fully detailed and cost loaded (cost to be loaded as a single Activity Budgeted Cost, as detailed later in this document) and resource loaded. With the exception of level of effort activities, individual activities Program and during the first 30 days should not have durations greater than 21 working days; where the GC believes an activity needs to exceed this limit it should be noted along with a rationale in the accompanying narrative.

This Program is to be used for progress monitoring while the Baseline Program for the entire contract is developed, and shall be developed and organized consistent with the requirements for the Baseline Program, unless otherwise directed by the CS.

1.3.2 Narrative

A narrative shall accompany the Preliminary Program, and subsequent Monthly Reports that describes the key aspects of the submitted Programs. The narrative shall describe what is to be delivered by the GC at each of the agreed interim milestone dates. The Preliminary Program narrative shall define the primary aspects of the GC’s plan for conducting the works including, but not limited to:

1. The logic used in the Program, list of constraints and their justification, any suspended work and any additional information as requested by the CS.

2. Critical submittals, review periods and long lead items.



3. The critical path, as defined. 4. An overall float analysis. 5. Any interface concerns with third parties (input by other parties to be identified). 6. Productivity and other assumptions made to determine activity durations and/or lags.

7. Risks that could impact the Program (per activity and/or WBS level). It is assumed that all internal risks are controlled by the GC in such a way the he will meet his contractual completion dates. Risks will be produced and maintained in a Risk Register in a format which will be provided by the CS. The CS may require specific mitigation measures to address risks detailed in the Risk Register and may also require this process be repeated throughout the execution of the Contract as part of a comprehensive Risk Management Process.

8. Cost

9. Man Hours (Resources Details)

1.3.2.1 Critical Path

In addition to preparing the Preliminary Program according to the above requirements, the Program shall also be sorted by critical path and presented as such. This is a time- scaled Gantt chart showing only the current critical and near critical paths of the works (activities with total float of less than one day).

For this program and all other programs, the critical path is defined as the driving sequence of activities leading to the completion of the project and/or intermediate contract milestones. Near critical paths are those paths not driving the completion of the project or intermediate contract milestones, but whose float values are within one month or less of the aforementioned driving critical path(s)

1.3.3 Baseline Program

The Baseline Program is a detailed Program that includes a narrative, cost curve and man-loading curve developed using the critical path method (CPM). It represents the GC’s execution plan for the work from the date of award onward. Once the Baseline Program is accepted by the CS, it shall not be revised, changed or modified without the CS’s consent. With the exception of level of effort and long lead procurement activities, individual activities should not have durations greater than 21 working days; where the GC believes an activity needs to exceed this limit it should be noted along with a rationale in the accompanying narrative. Such deviations shall require approval by the CS.

The Baseline Program shall be submitted within 60 calendar days from the date of execution of the Contract Agreement.

1.3.3.1 Narrative

A narrative shall accompany the Baseline Program that describes the key aspects of the submitted Program. The narrative requirements will match those detailed in Section 1.3.2. Above.


In addition to preparing the Baseline Program according to the above requirements, the Program shall also be sorted by critical path derived by the Baseline Program and presented as such. This Program shall show the critical path derived from the Baseline Program. This is a time-scaled network logic diagram showing only the current critical and near critical path(s) of the works along with its current progress.

1.3.3.3 Resource Loading Curve

Manpower, Equipment and Cost loading curves shall be developed as part of the Baseline Program. For manpower, the curves shall show overall manpower required for the works and what disciplines make up the overall manpower.

1.3.3.4 Detailed Program

On award of any subcontract associated with Cost, the GC shall obtain or produce a Program covering the Sum of works, incorporate it into the Baseline Program and submit it for approval.

The Program for Sum work shall comply with all requirements of the Baseline Program including but not limited to duration limits, WBS and coding.



1.3.4 Progress Program

The first update to the approved Baseline Program forms the first progress Program. Subsequent progress Programs shall be submitted on a monthly basis presenting the update for the previously issued progress Program. The progress Program shall also be used to:

1. confirm the physical percent complete requested by the GC in progress payment applications;

2. Analyze delays and impacts using Time Impact Analysis (TIA) and determine whether a recovery Program is required from the GC.

The progress Programs shall conform to all requirements of the Baseline Program.

For all progress Program submittals, the GC shall submit a printed list of all Program logic changes along with the reason for each change, as produced by Claim Digger included in Oracle Primavera P6 Professional Project Management tool. This list is an integral part of the Program submittal. This list shall be generated from the scheduling software and be the same logic included on the submitted CD/DVD. The Employer shall accept this list as part of its overall progress Program submittal review and acceptance process. Additionally, the progress Program submission shall contain the updated manpower loading curve.

The progress Program shall be updated and submitted once a month.

• Submission (Month Ending Update): The update period will include progress between the morning of the 1st day of the month through the end of the last day of the month and be electronically submitted by COB(Cutt of Bussiness) 7 calendar days after the Data Date. The Data Date will therefore be the 1st day of the following month regardless of whether it is a work day or not. The intent of this submission is to provide a full progress update consistent with provisions 1.3.4.1, 1.3.4.2 and 1.3.4.3 below.

Progress Programs shall be submitted monthly to the CS, or more often if required.

1.3.4.1 Narrative

The GC shall submit a monthly narrative for each monthly period beginning on the 1st and extending through the last day of the month. These submissions are required to be stand-alone documents and shall not require their corresponding progress Programs to be attached in order to understand the narrative. The narrative, along with all required corresponding reports, will be electronically submitted by COD (Cut of Date) 7 calendar days after the data date (or first work day thereafter) of each month for the previous month’s update.

The narrative shall address the following, without limitation:

1. Planned and actual progress in the reporting period.

2. Critical path progress and concerns.

3. Potential delays.

4. Submittal status (focus on critical submittals and concerns).

5. Revenue to-date; Earned Value and associated performance metrics as directed by the CS.

6. Variances. The GC shall provide a written narrative to include the cause(s) of all Program variance(s) related to a forecasted delay in any contractual milestone completion or activity dates.

7. Potential Risks and corresponding Mitigation Strategies.


In addition to preparing the progress Program according to the above requirements, the Program shall also be sorted by critical path derived first by the Baseline Program and subsequently, from the current progress Program.



This is a time-scaled network logic diagram showing only the current critical and near critical paths of the works along with its current progress.

1.3.4.3 Resource Loading Curves

The resource loading curves shall be updated in accordance with the progress Program to show the actual resources deployed compared to the Baseline Program.

1.3.5 Look Ahead Program

The GC shall prepare, for presentation at weekly progress meetings, a detailed Look Ahead Program showing specific activities scheduled for the three (3) weeks from the preparation date and also showing activities in the previous week. In addition, a 90-day rolling window Program shall be updated and presented weekly during progress meetings highlighting milestones, submittals and critical path activities.

1.3.6 Recovery Program

Should any conditions exist, such that certain activities shown on the GC’s progress Program fall behind schedule to the extent that any of the mandatory critical dates or milestone completion dates are at risk of being delayed, the GC shall be required, at no cost to the Employer, to prepare and submit to the CS a supplementary recovery Program(s). The recovery Program shall be in a form and detail appropriate to the need and to explain and display to the CS how the GC intends to reschedule those activities to regain compliance with the last previously approved progress Program, without EOT (Extension of Time).

The Program shall be accompanied by a narrative describing what steps the GC proposes to recover slippage. Timeliness will be critical when submitting the Recovery Programs; therefore, all Recovery Programs will be submitted no later than two weeks after it is discovered that any contractual milestone is delayed. Failure to comply may result in partial withholding of that month’s application for payment, until such Program is provided to the satisfaction of the CS. The GC will re-submit said recovery Program(s) until they are approved by the CS.

After the CS determines that a recovery Program is required, the GC shall prepare and submit for approval to the CS, the recovery Program. The recovery Program shall represent the GC’s best judgment regarding how the GC’s work shall be re-organized such that the work may return to the accepted progress Program; this plan will expressly be understood so that there is no additional cost to the Employer until such time that entitlement for compensation is established regarding delays claimed by the GC in association with such plan. The recovery Program shall be prepared at a similar level of detail as the progress Program and shall be based on the accepted progress Program.

No later than five days prior to the expiration of the recovery Program, the CS and GC shall meet to determine whether the GC has regained compliance with the approved progress Program. At the direction of the CS, one of the following will occur:

If, in the opinion of the CS, the GC is still behind schedule, the GC shall prepare another recovery Program, at the GC’s expense, to take effect for a maximum of one additional month from the start of the new recovery Program or as agreed upon with the CS.

If, in the opinion of the CS, the GC has sufficiently regained compliance with the progress Program, the use of the progress Program shall be resumed.

1.3.7 Extension of Time Program

In the event that conditions exist such that the GC believes there are grounds for an extension of time for any contractual milestone, the GC shall submit as part of his application a Program showing how the works have been impacted by delay events. The Program will be used to demonstrate entitlement and shall be the progressed Program in place at the time of the occurrence of the delay event; the method of calculation shall be Time Impact Analysis (TIA). Submission of the TIA does not imply entitlement; all TIAs will be evaluated for entitlement and may be rejected if they are found to be unsubstantiated in the opinion of the CS.



Where entitlement is claimed as a result of a change of scope to the works, the GC shall produce a Program fragment that demonstrates the impact of the change against the schedule in effect at the time of the change.

As part of the TIA submission, the GC shall include a Mitigation Plan which eliminates or reduces the effect of the delay to the greatest extent commercially practical, including associated costs for such a Mitigation Plan.

As part of its TIA submission, the GC must demonstrate that there are no concurrent delays caused by the GC, or by any other cause which would render the extension of time non-compensable (e.g. force majeure impacts). This analysis is a condition precedent to compensation for the delays included in the TIA, subject to the other terms and conditions of the Agreement.

1.3.8 Variation Requests

The GC shall provide a detailed Program in accordance with the Baseline Program requirements with each variation request. The submitted Program shall detail the impact of the variation on any impacted project milestone, interface point, and overall completion date, as well as detailing the plan for executing the work proposed by the variation (V.O). The variation activities shall not be incorporated into the Progress Program submission until the variation request has been approved by the Employer.

1.4 REVISION AND UPDATE

During the course of the works and issuance of the progress Programs, updating to reflect actual progress shall not be considered revisions to the Program. Such updating shall include revisions to activity remaining durations, original durations and certain sequences on a monthly basis. Included in the progress Program updates shall be activities and changes that have already been reviewed and approved by the CS such as the effect of accepted Employer changes, the agreed duration of delays caused by acts of God, or other conditions or events which have affected the progress of the works. The progress Programs, when formally submitted, shall display current progress as well as displaying the forecast or projected works completion.

Should the GC, after the CS’s approval of the Baseline Program and any progress Programs, desire to change the Program logic, the GC shall submit in writing its requested revisions to the CS. The request shall include a written narrative of the reasons for the activity and logic changes, a description of the logic for rescheduling the work and the methods of maintaining adherence to critical and milestone dates.

Additionally, for changes affecting sequences of the works, the GC shall provide a time-scaled logic diagram that compares the original sequence of work to the requested revised sequence of work, or a Gantt chart depiction that uses as a target the original baseline such that changes are readily observable. The GC shall submit the requested revision in a timely manner such that the CS may review the requested submittal in the same time frame and manner as required for other Program submittals. Upon the CS’s approval of the request, the GC shall include the revision in the next progress Program submission. If the GC does not receive approved changes from the CS, that will not relieve him of preparing the next months updates with the best available information.

Neither the updating or revision of the GC’s progress Program, nor the submittal, updating, change or revision of any Program (or Program document) for the CS’s review and approval shall have the effect of amending or modifying, in any way, the period for completion of the Contract Agreement works, any completion date, or agreement milestone dates or of modifying or limiting in any way GC’s obligations under the Contract Agreement. At a minimum, the GC’s progress Program logic shall be updated at the end of each major phase of work.

1.5 REVIEW

1.5.1 General

All Program documents shall be formally reviewed as required by the CS and returned to the GC with the required acceptance or action(s) as noted. The CS shall be allowed 14 days for initial submission review and seven days for



re-submittal reviews of the Preliminary Program and Progress Programs and 21 days initial submission review and 14 days for re-submittal reviews of the Baseline Program.

1.5.2 Review Comments

The CS may use the word “accepted”, “not accepted”, or variations thereof in conveying its review comments to the GC regarding review comments on Program (and Program document) submittals. Any time the word “accepted” or similar wording is used, such wording shall have no different meaning than similar wording such as “No Exceptions Taken”.

1.5.3 1.5.3 Supporting Document

• Appendices included in this SOP:

o Appendix 1 – Baseline Review Check List

o Appendix 2 - WBS Request Change Form

o Appendix 3 - Form PC-1 - Request for Planning Code

o Appendix 4 - Form WBS-1 - Request for WBS Code

o Appendix 5 - Form WBS-2 - Request to Modify WBS

o Appendix 6 – Uniformat ASTM Form WBS

o Appendix 7- Sample Uniformat WBS Structure

TBC-RSDP Project Management Plan

Revision 0 - 17-Feb-2015This CMP is a Guide only and does not replace or override Project Contract Documents. Page 13