Scheduling Handbook for Turnaround

 

I. Introduction

This handbook provides guidelines and best practices for external schedulers working on our turnaround events. The primary goal is to ensure a safe, efficient, and predictable turnaround by adhering to a dynamic and collaborative scheduling approach. Our methodology is built on a foundation of real-time data, proactive communication, and continuous optimization.

II. Scheduling Philosophy and Methodology

1. The Core Philosophy: From Static to Dynamic Scheduling

Traditional scheduling relies on a static, "plan-and-execute" model. Our approach, inspired by Dynamic Scheduling Methodology(DSM), recognizes that a turnaround is a complex and ever-changing event. We shift from a rigid schedule to a flexible, living document that adapts to the realities on the ground. This requires a mindset of continuous improvement and a willingness to respond to new information as it becomes available. Static scheduling is about measuring variance against the plan. Dynamic scheduling (DSM) is about continuously recalculating and re-optimizing the plan to drive.

2. The Three-Phases Scheduling Methodology

Phase One: Strategic Planning & Schedule Foundations

The objective of this phase is to create a validated, resource-aware, and logic-driven baseline schedule that integrates all turnaround scope, highlights risks, and establishes a foundation for monitoring and control.

2.1. Establish Schedule Foundations

The schedule is initiated by setting up a new project in the Primavera P6 database. The first step is to export approved work scope from SAP into P6 to populate the project with activities.

2.2. Define Major Milestones

All project major milestones and key dates must be included in the schedule. They must be logically linked to the network of imported activities, ensuring they are actively driven by the schedule logic, not just "floating dates." Examples include:

•  Project Start/Finish dates

•  Material delivery dates

•  Key interface dates

•  Key pre- and post-commissioning dates

2.3. Establish Work Breakdown Structure (WBS)

The WBS is the standard hierarchy in which work is organized. It serves as the backbone of the schedule, linking scope to project controls reports. The required WBS levels are:

•  Level 1: Site (e.g., PHOS)

•  Level 2: Plant (.g., Ammonia, Beneficiation)

•  Level 3: Process System

•  Level 4: Work Order

•  Level 5: Operations Tasks

2.4. Implement Schedule & Activity Coding

Activity codes are used to filter, group, and sort information. They must be implemented early to capture all possible reporting requirements and avoid quality issues later.

Recommended codes include:

•  Plant name

•  Work order

•  Turnaround phases

•  Priority codes (useful for DSM operations)

2.5. Define Schedule Calendars

The scheduler must create and assign the default project calendar, which defines normal working shifts, holidays, and exceptions. The baseline schedule must also accommodate weather events. This ensures that durations and resource plans reflect real working conditions. The guideline recommends specific shifts for different work groups, such as 7D x 12Hrs x 2Shift.

2.6. Develop a Project Resource Dictionary

The schedule must be resource-loaded to align with the project estimate. This requires two main steps:

1.  Developing a Resource Dictionary of all possible resources (labor, equipment, tools).

2.  Creating a Table of Required Resources in P6 and assigning them to activities.

Phase Two: Schedule Development & Quality Control

The goal of this phase is to build one unified, CPM-driven baseline schedule that logically links all activities across pre-work, execution, and close-out, ensuring float, dependencies, and sequence are visible and controllable.

3.1. Schedule Development Principles

Stakeholder Involvement: The scheduler facilitates the process, but key project personnel (e.g., project leads, engineering, operations) must be consulted to provide input on sequence, constructability, and resource usage.

Resource Loading: The schedule must be resource-loaded with man-hours and specific equipment, enabling reports at several levels of detail.

3.2. Schedule Logic Rules

The logic must be sound to support the CPM. Core rules include:

•  No open-ended activities (every activity has a predecessor and a successor)

•  Logic-driven dates rather than manual constraints

•  No negative float or negative lags

•  Retained logic must be used during updates

3.3. Schedule Quality Checks

Before approval, the schedule must be checked for:

•  Sound logic and a valid critical path

•  Minimal use of hard constraints and negative lags

•  No excessive float (which could indicate missing ties)

3.4. Basis of Schedule Document

The Basis of Schedule (BoS) document provides a narrative that defines the principles, assumptions, and specifications used in the schedule's development. It is the "user manual" for the plan, containing details on scope, constraints, risk mitigation strategies, and outstanding issues.

Phase Three: Execution & Progress Monitoring

The objective of this phase is to execute the baseline plan to meet the established KPI targets using a dynamic, real-time control system.

4.1. Baseline & Current Schedule

Once approved, the schedule is signed off and saved as the Baseline Schedule, which is the frozen target for measuring performance. A copy is then used as the Current Schedule, a live, updated version maintained throughout the project.

4.2. Primavera Scheduling Options

The handbook specifies that schedulers must use a consistent set of standard Primavera settings to ensure uniformity and support dynamic calculation. This includes using retained logic and defining critical activities as those with float less than or equal to one shift.

4.3. Progress Monitoring & iPMS Integration

iPMS (Intelligence Progress Monitoring System) transforms progress monitoring from a reactive exercise into a proactive control system. Field progress, captured via tablets or mobile apps, is fed into iPMS and then automatically pushed into Primavera. This enables:

•  Near-real-time visibility of the critical path

•  Dynamic adjustment of the plan based on actual performance

•  Automated reporting and analytics

4.4. Schedule Reporting

Reporting is critical for communicating project status. The scheduler must provide a narrative analysis with each report, which should include:

•  Schedule Summary & Critical Path

•  Summary of Progress & Slippage Reports

•  Resource Histograms & S-Curves {developed outside P6 with input from the schedule)

5. Post-Turnaround Scheduling Guidelines

This final phase closes the loop and ensures continuous improvement.

•  The as-built schedule is frozen to preserve a final record of actual performance

•  A Variance Analysis is conducted to compare the final schedule against the baseline

•  Lessons Learned from the event are documented to improve future planning

•  Historical iPMS data is used to calibrate productivity factors, durations, and

resource curves for the next turnaround.