Not all Schedulers are Equal

You Work in the Role You Have Been Given

The scheduler role depends heavily upon the type of schedule they are maintaining. More to the point, the scheduler role is not typically interchangeable with other types of schedulers. As an example, a CMMS drag-drop scheduler could not easily jump into a shutdown/turnaround/outage role as the software, process and terminology is different. The CMMS scheduler progresses the work order (and task records) whereas the outage scheduler progresses the activities. Plus there could be more detail activities in the scheduling software than there are in the CMMS.

Outage/Shutdown/Turnaround (STO) Scheduler

This role may be the most intense in that there might be thousands of activities and twice that in logic ties. The 2nd challenge is gathering progress on a daily (or shift) basis. There can be many activities "crossing the datadate" each update period. The scheduler has to address all of these. Some will get bumped, and others receive progress. The scheduler must get these updates from the lead craft -- typically in a status update meeting.

The Secret to Building a Tight Schedule

This type of schedule also means the plant is shutdown which adds a "cost of lost production". Leadership is very focused on ensuring the critical path as tight as it can be. A schedule can be tightened by adding resources, shortening durations, altering logic ties, and working around the clock. The secret to building the best possible schedule is to conduct many reviews, by different types of skillsets. A power plant may regularly employ a operations shift supervisor in the planning/scheduling department for this purpose. This person would be responsible for validating the entire critical path. And the outage manager may request mock-ups of work on the critical path before the outage starts. A schedule of this type is prepared many months in advance so that scope can be frozen and all materials staged.

Some Outages Are Big and Some Are Small

Shutdown/Turnaround/Outage duration can be small or large. An example of a small outage is 72 hours or possibly up to a week. A STO event could be forced (not scheduled) or scheduled in advance. For short duration events, the time it takes to make a formal schedule may not be worth it. Thus, leadership may opt to just work from a list (either from CMMS, Excel, or MS Word) as opposed to a schedule with logic ties.

Some Project Schedules are For Show

Some projects simply need a schedule to get started. In other words, there is a contract requirement to have a schedule. Unfortunately, many of these IT (software) project schedules never get updated once started as the time required to update (capture progress and make on-going refinements) is too much.

Similarly, with weekly maintenance schedule, if this document is just a list of work, then the work force will (1) see more work than is possible, (2) believe that some is optional, and (3) it is up to them to determine what is important. This hands-off approach by management often results in a work force not being maximized and backlog reduction strategies not optimized.

CMMS Integration

The primary benefit behind CMMS integration is so that the schedule activities that originated from the CMMS do not have to be re-keyed by the scheduler. As a secondary benefit, the scheduler can update the CMMS work order "schedule dates". But for reporting purposes it may be just as easy to produce the official schedule report direct from the scheduling software in bar chart format. The above process is intended for the drag-drop scheduler.

WBS Integration

The purpose of a work breakdown structure [WBS] is to (1) identify scope and deliverables, (2) store budget, (3) track contingencies, and (4) produce rolled-up cost reports. For larger projects and STO schedules, it is very important that the outage manager controls scope. It may seem that they can add work mid-outage but discover this added work suddenly becomes the critical path and extends the STO finish.

Note: There are some power plants that are not concerned with locking down scope before outage start, such that they will make adhoc decisions during the outage and bring in new work.

The CMMS Scheduling Vendors are Focusing Solely on Drag-Drop

I’m not exactly sure why this is the case, but as of this post date, there is only a desire to provide a mouse-driven display which (1) allows placement of a work order under a day of the week, and (2) linkage of the craft/labor code to the job. This interaction also shows immediate changes to resource availability. Conversely there is no desire to accommodate other types of schedules involving logic ties, critical path calculations, or progressing. The weekly maintenance schedule drag-drop process is usually done in the presence of the craft supervisor so that both of their time is consumed. All up, this is an inefficient process involving subjective selection.

Areas of Concern

Management teams are generally not aware of the scheduling process within daily/weekly or of outage-shutdown management. They may think they know but very few of them are aware of schedule formats, surrounding process and supporting roles. Hence, when they see a software product as demonstrated by a CMMS Scheduling vendor, they immediately think this product handles all aspects of the scheduling world. And before you know it, a software purchase is made without conducting a comprehensive review of all scheduling needs resulting in a requirements document.

The drag-drop design is merging the concept of weekly schedule with daily plan creation. I see this as a problem, The selection of work from a backlog should have been automated based on work order ranking against craft availability. This process would have created a “set of work” for the week, and greatly enhanced the speed of creation. Then the maintenance supervisor, by himself, could have created the daily plan (one day in advance) (using the drag-drop feature) to accommodate for plant dynamics and carryover work.

Sometimes Automation is Not Possible Because the Data is Not Good

Even if there was an automation option for resource leveling, the schedulers can not use this option because there are just too many inaccuracies with the backlog. Examples include inaccurate WO statuses, poor prioritization, missing craft estimates, and inaccurate craft availability. If these data issues exist, then the only way to create a weekly schedule is with a manual process. There is an exception to this rule, if this workaround is considered.