Applied Systems Thinking for Turnaround Execution, Dynamic Schedule Methodology.

An article by Laszlo Kardos, PMP, PEng and Peter Reier

This is the third article in our Series, "Systems Thinking is Shaking the Tree!", in which we are proposing that Dynamic Schedule Methodology for Turnarounds is, by any definition, an Applied Systems Thinking solution for the real challenges of Turnaround Execution.

We outlined our Premise in Issue #21 of STO Realities… https://www.dhirubhai.net/pulse/systems-thinking-shaking-tree-peter-reier/

Issue #22, spoke to “What is Systems Thinking” co-authors Michael Woudenberg and Carl "C.J." Unis walked us through the definitions with brilliant case studies.

https://www.dhirubhai.net/pulse/systems-thinking-skills-insights-solve-wicked-problems-peter-reier/

This is STO Realities Issue #23 and this article speaks to the particulars of Dynamic Schedule Method, more specifically we will demonstrate why DSM is without question an example of Applied Systems Thinking; and why this is game changing in the world of Turnaround Execution.

This is not a “how-to” article for Dynamic Schedule Methodology, or Dynamic Execution Management, what we will speak to here is two fold;

• First off, why do Turnaround Project Schedules Require a different approach in the first place, in the language we used in Issue #22 – why is Turnaround a “Wicked” problem?
• Second, how does the DSM approach turn a Standard P6 project schedule into an Applied Systems Thinking management tool?

Let’s begin with the why, the very specific why that every Turnaround Schedule and every Turnaround Manager is faced with every single day of execution…

“Why is the schedule so complicated, and continually changing, and why is everything moving, everyday?”

The schedule is so dynamic because most of the scope is not suited for the Critical Path Method scheduling methodology.

The last 4 Turnarounds I scheduled; 2018 and 2020 were High Complexity; 2019 and 2021 were Medium Complexity.

Focusing on 2020 which had just shy of 32,000 activities,

• ?I found that 185 activities represented the longest path,
• ?If you included forced criticality, activities with zero float due to constraints, I had 1001 activities,
• If I included near critical, activities with less than 72hrs float, I had 2100 activities.?
• That leaves nearly 30,000 activities that still need to be scheduled in a way that makes sense.

The point I am trying to make is that the deterministic longest path is likely in the order of <1% of the activities in the turnaround schedule.?

With Longest Path plus the probable near-longest path contenders; an average of <10% of the activities can be “scheduled” with traditional scheduling techniques.

From this we can see that CPM and PERT/Monte Carlo -- as useful as they are, and they are useful -- are not effective at “scheduling” most of the activities in your turnaround schedule.?

• Yes; you still need to utilize CPM and to optimize your longest and near-longest paths;
• You should still do PERT/MCS, to better understand the risk of going long, … Considering how costly it is to go long, it is not unheard of to spend a year trying to shave one day off a turnaround schedule.
• I suggest also putting more effort into dealing with the other 90% of the activities, this is where the benefit is in terms of optimizing resources, crane usage, etc, etc., the longest path is a fixed sequence; and once you have agreed on it there is no wiggle room; everything else has to move.

Since most of the activities in a turnaround schedule are highly dynamic, we need an approach that is also dynamic.

Flashback to Issue #21…

The Systems Thinking approach places emphasis on the importance of “Feedback loops”, and “non-linearity" as well as an understanding of emergence, to be able to understand the impact of changes and decisions within complex and dynamic systems.

Problem, meet Solution.

If you have not heard of Dynamic Scheduling Method, we will now introduce you to the ways we have implemented this concept.?

Some key elements of a Dynamic Schedule include:

• Milestones, lots of milestones
• Event level; Unit level, Process System level, and Work Package level

There are also some scheduling best practices that aid in developing a schedule that is responsive to change and more readily believable.?

This includes the use of:

• Meta-data
• Systemized Logic Flow
• Phased and Productivity Adjusted Calendars
• Activity Priority Codes
• Optimization of the Longest and Near Longest Paths
• Resource Leveling
• Float Control

Turnarounds are simple …. Shutdown, do the work, check the work, and start-up.

Although there will likely be pre-work and post-work in your schedule, the focus in this example is from Pull Feed to On Test.

The basic systemized logic flow of a turnaround schedule has the following requirements:

• All activities must be able to trace their logic back to the Pull Feed milestone
• All Shutdown activities lead to milestones that represents System Release to Maintenance (RTM)
• Maintenance execution activities start with an operations LOTO activity, and finish with a Contractor QC Activity and Pre Start-Up Safety Review, the PSSR
• All Maintenance execution activities can be traced to a milestone that represents the release of a system back to operations (RTO)
• System releases drive the yellow lining of each system and Unit PSSR; which drives the startup of the unit
• On Spec represents the completion of the Turnaround

Integration

The Systems Thinking approach to anything places high emphasis on elimination of Siloed management and decision making.

In the case of turnaround let’s spell that out because this is easily the single most common “deliberate” sabotage of turnaround success.

• One Process and Process Timeline, the Turnaround Process; all participating teams and PMs will fall under governance of the TA Process and Team.
• One Team, as in full integration, leave inter-silo infighting on the playground.

Schedule optimization is a significant indicator of competitiveness and is considered a key success factor.

This requires that all scope items executed in the turnaround time frame are included in a single integrated schedule.

Following the identification and development of Longest and Near-Longest Paths utilizing CPM; schedule optimization is achieved utilizing key meta-data such as

• Unit, Process System and Piping Circuit,
• Geographic location, and elevation
• Multiple priorities; such as First Third inspections priorities and System Return to Operations priorities

All this is to “program” P6 to produce a computer-generated schedule.?

This is followed by in-person execution feasibility reviews with Planners, Field Coordinators, Construction Representatives and Contractor execution supervision.?

Process Systems are consistent with JDE or SAP systemization information.

We assign priorities to each process system.?Priorities are two staged;

a) Priority between Plants/Units, and

b) Process System priority within the Plant/Unit.

Shutdown sequence priority is applied to Pre-turnaround and Shutdown phases of the schedule

Startup sequence priority is applied to Execution, Startup phases of the schedule.

We assign Compliance Inspection priorities to all fixed equipment (columns, vessels, reactors, exchangers, and furnaces).

The priority assignments are relative to the risk of discovery work in the first third of the event!?

We identify the top 5 critical-longest path process systems (not jobs); the top 5 process systems touched by the longest and near-longest paths through the schedule.?

Ensure that all scope in those systems has been considered.

In this context, the process system path duration is from Release to Maintenance (RTM) to Release to Operations (RTO) for each system.?

The longest system, in each Plant/Unit, drives Unit PSSR.

Schedule optimization is not a stand-alone activity; it is an iterative process requiring several passes.

Depending on the number of jobs, number of process systems, turnaround complexity, and availability of key reviewers, the reviews can take several months, and they do require significant effort to complete.

Shutdown and Startup are not necessarily based on ‘process system’, at most sites there may be too many complex interactions to consider shutdown and start-up by process systems; hence the fact that all process system PSSR milestones drive Unit PSSR, which in turn drives Unit start-up.

This can create complicated inter-unit startup dependencies in a multi-unit event.?The shutdown and startup windows can represent 25-40% of the overall event duration.?

It is a mistake to think of Shutdown and Startup as singular events.?

If we do not start any work until the last Process Unit is RTM, and then we propose that every unit must be complete at the earliest required Start up date, we create an entirely artificial and needlessly restrictive time on tools curtailment across the entire event, as is obvious in the above graphic.?

Calendars

“How much wood could a woodchuck chuck, if a woodchuck could chuck wood?”

AKA – Time On Tools.

There is scarcely a more controversial discussion on plant site, the truth can be summed up in the simple statement…

“A great deal less than the Steering Team and Strategy Team want to believe, but this isn’t about beliefs, this is not theology, this is facts and data.

Unless we do this part with a commitment to Truth over Desire… everything else fails!

We plan ”Time-On-Tools” as the basis for job activity durations and we utilize productivity adjusted calendars in P6 to account for productivity losses.

A 60% calendar (6 hours on tools in a 10 hour shift). This represents the time-on-tools versus time paid for.?

The inverse of 60%, 1/0.60 = 1.67 represents the Productivity Factor multiplier to take Direct Field Labour hours to hours you need to budget for (i.e.:?100,000 hrs DFL at 60% time on tools = 167,000 workforce hours thru the gate; @ 50% time on tools that is 200,000 workforce hours thru the gate).?

Acknowledging productivity and utilizing such calendars has been a primary contributing factor leading to more realistic event schedules.?

?

Without getting crazy complicated, possible ways to implement this, consider:

• Unit specific calendars.?Each unit could have a different default.
• Location specific calendars for certain jobs or critical sequences only.?Perhaps 65% at grade and 40% at top of column.
• Gradual, timing-based adjustments to account for fatigue.?Perhaps in the first rotation 65%, second rotation 60%, third rotation 55%, fourth rotation and beyond 50%.

Not all resources require the same adjustment.?We should however focus on the critical trades that drive the critical/longest path (i.e.: PF / PFW).

Global Calendars from the basis of Project Specific Calendars, and Resource Calendars

Starting with a set of global calendars,

• We create Project Specific Calendars, and
• We create a set of Resource Calendars

……?G-60%_7x10x2 = Global

……?P-60%_7x10x2 = Project Specific

……?R-60%_7x10x2 = Resource

We create as set of “phased” Project Specific Calendars as required.?Phased calendars define the start or the availability of a particular phase.

• Pre-work
• Shutdown
• Execution
• Startup
• Post

Resources

Unlevelled implies unlimited resource availability

Levelled resources implies limited resource availability

We don’t want leveling to extend the duration a Turnaround; therefore we need a way to enable float control, we utilize 2 key P6 scheduling options:

Level within activity total float, and

Make open-ended activities critical (this gives open-ends zero Total Float).

Leveling is an art requiring creative thinking.

• The schedule must be scope and logic complete and fully resource loaded.
• Good leveling relies on activity attributes, including priority coding, resource assignments and limits, logic, and float.?Ensure all these attributes are in place prior to leveling.
• Activities on the longest path, with zero float, are not affected by leveling because we level within activity total float.

Utilizing a combination of several Activity Codes, Resource Leveling allows P6 to accomplish the task of precedence scheduling quickly and enabling the ability to test multiple scenarios.

Because P6 can consider so many possibilities, the result is a schedule that more accurately reflects the desired sequence of activities based on dynamic priorities and limited resource availability.

Utilize multiple leveling related priority codes to “program” P6 to select activities in accordance with multiple objectives; for example:

• Job Criticality
• Activity Leveling Priority
• Unit / System Turnover Leveling Priority

You can change leveling priorities during execution to accommodate the dynamic nature of Turnaround execution. For example, we may

• Re-assign priorities on the fly to capture changes in strategy due Field Coordination conversations.
• Revise priorities due to inspection results.
• Changing priorities to align with an alternative startup strategy.

Since leveling relies on “Float”, float control is extremely important.?

However, there are problems with constraints in this regard …

• The most significant problems with constraints are that they are Date Specific, they are not dynamic; and can create negative Total Float.?
• Activities with zero or negative float cannot move when resource leveling.?So sprinkling constraints throughout your schedule that will likely generate negative float, cripples the ability to level resources.

Soft Constraints; constraints where the logic has priority driving the dates of a constrained activity not the constraint date.?Furthermore, soft constraints …

• Can alter critical / longest path
• Can generate negative float
• Can break visibility of true longest path

Hard Constraints, constraints where the constraint date has priority over the logic.

• Activities with a hard constraint will be adjusted regardless of Total Float, breaking logic; however, only the activity with the constraint will be adjusted.
• This can wreak havoc in understanding Total Float of predecessors, especially when there are multiple float paths impacted by the constraint..

“Constraints are a Troubleshooting nightmare”

To facilitate float control, we utilize concept we refer to as Shadow Milestones.

So, what are Shadow Milestones and how do they work?

Eliminate all hard and soft constraints, and utilize two key P6 scheduling options:

• Make open-ended activities critical;
• Level within activity Total Float.

Do not measure performance based on Total Float; assess performance of key milestones using Baseline Variance.

Most constraints can be replaced using availability calendars and Shadow Milestones.

Prior to using Shadow Milestones, the schedule must still adhere to the scheduling principle that there are only 2-open ends in your schedule.?

Shadow Milestones are duplicates of key milestones on the schedule; milestones which are a form of constraint on sequences in the schedule:

• These sequences are intended to have most compact timeline possible; they are driven by the duration of the preceding scope of work
• The shadow milestones are the end of an important sequence of work that is not intended to be impacted or affected by resource leveling; the sequence is intended to have zero float.
• Shadow milestones do not have any successors; they are open ended and considered to be critical by P6.

We utilize a Shadow Milestone rather than constraining the Unit PSSR completion milestone.

• This always provides Zero Float to that milestone.?Why is this important?
• Because if your schedule is slipping relative to a typical Constraint, any negative float in your schedule will impede the ability to level resources.
• With the use of Shadow Milestones, leveling within activity Total Float, Total Float remains relative to the longest path.
• Shadow Milestones will not create a negative float scenario.
• We assess status of key milestones, are we ahead?, are we behind?, by referring to Baseline Variance.

Shadow milestones can be utilized to control float for critical or ”important” sequences of of work.

In this example there is an important milestones in System C that requires a constraint.?

Using one to the traditional constraints could generate negative float to such an extent that it renders resource leveling to be unachievable on more than just the intended sequence.

By introducing a Shadow milestone, we can control float to be zero to that point.?

This minimizes the duration from C to Important Milestone, this is what we refer to as forced criticality.?

This methodology, utilizing “Shadow Milestones”

• Respects logic,
• Enables float control, where required
• Does not create negative float,
• Does not alter or break the longest path, as the longest path is still the longest path, and most importantly ….
• A shadow Milestone is dynamic, moving with the ebbs and flows of the ever-changing schedule as the schedule is progressed

Consider a Shadow Milestone as a new dynamic constraint type ….

“Finish As Soon As Possible”.

1. Planning, is left-brain; logical, rational, and calculating
2. Scheduling, is right-brain; artistic, creative, and dynamic
3. Critical/longest path via CPM is not necessarily the path that will become the longest path and delay your Turnaround!
4. Without Monte Carlo Simulation there is no credible confidence in the completion date.
5. Furthermore, CPM and MCS are not effective in scheduling most of the activities in a turnaround schedule.
6. Dynamic Scheduling Methodology provides a suite of creative techniques that respect the dynamic nature of Turnarounds.
7. A key DSM technique is float control via the use of Shadow Milestones.

• Leveling within available float remains relative to the longest path, and
• Shadow Milestones will not create a negative float scenario, ensuring resource leveling if functional for the entire event, regardless Baseline Variance.

Now that we have addressed a credible duration estimate, and a means of scheduling in a way that is responsive to the dynamic nature of Turnarounds, we now turn our attention to Dynamic Execution Management.?

Conclusion

Dynamic Schedule Methodology is an example of applied systems thinking.

It takes a holistic, interdisciplinary approach to Project Management.

It recognizes that projects are complex systems made up of interconnected elements, and that the behavior of a project can only be understood by examining its various components and how they interact with each other.

Dynamic Schedule Methodology uses a system dynamics approach to model the behavior of a project over time.

This approach takes into account the feedback loops, nonlinear relationships, and time delays that are inherent in complex systems.

By doing so, it provides a more accurate picture of how the project will progress, and it helps identify potential issues early on, so they can be addressed before they become major problems.

The methodology also emphasizes collaboration and communication among all stakeholders in a project.

By involving everyone in the decision-making process and ensuring that everyone has a clear understanding of the project goals, Dynamic Schedule Methodology helps to align the project team and create a shared vision.

In summary, the Dynamic Schedule Methodology uses systems thinking and its focus on collaboration and communication make it an example of applied systems thinking in project management.

Next Issue of STO Realities will continue the discussion. A lot of work and ingenuity went into creating a true Dynamic Schedule, so what do we do with it now...

Subscribe today to have STO Realities delivered directly to your inbox, including Issue # 24 which will discuss using DSM for Dynamic Execution Management

#generationalknowledge #executionexcellence