From Precision to Pragmatism: Redefining Scheduling for Realistic Project Success

There it is, the beginning of a project and this complex, multi-line, Primavera or MSP schedule is created typically by some fancy scheduler (maybe a PM), hopefully a superintendent, and ideally with some input from the sub-contractors.  Proud of a product that meets the owners technical requirements and shows how all the work will get done in time with one start milestone, one end milestone and a complex layer of activities that might make a watchmaker blush.  The owner can tell the exact day and time to the minute as to when their office door is going to be placed on floor 4, the carpet on the 50th floor will start, and when the owner provided fish tank will be ready for placement, four years into the future.  What’s an owner to do but approve such a beautiful product.

Then, as typical, day 1 of construction starts and that beautiful, harmonious schedule, is turned into as much rubble as an aging casino in Las Vegas.  Ties are broken, durations are changed, new activities are added, the critical path demolished and rebuilt.   The same thing happens day 2, day 3, on and on up until the final day of the schedule. Ultimately the entire schedule turns into a mess of legalese, technical schedule jargon, and contract requirements that benefits the lawyers and consultants on both sides, while the use of a schedule as an actual plan or prediction tool turns into a more of a MC Escher painting than that of a precise interwoven clock.

Why does this happen?

Planning and Scheduling is treated purely as a logic exercise.

Form/Rebar/Pour in Section 1 should take 5 days given the CY of concrete and average workforce, with a Finish to Start with the next similar sized section, repeated 200 times and viola… I know exactly what day, to the minute we’ll start section 198 (almost 4 years out).  Logical, yes, defendable, of course, reasonable… absolutely not.  If anyone could predict to the minute the start of an activity 4 years out, they could make a lot more money doing something else.

The probability of hitting exact dates/times as you go further and further out from your starting point obviously decreases over time.  We all know this, we all know this intuitively, we have all experienced this personally, whether in construction or in our personal lives.  For some reason we all completely ignore this lesson (that we have never seen work otherwise) when scheduling long, complex jobs. Yet time and time again we schedule large, complex jobs with pinpoint accuracy months and years into the future.

So how do we solve this?

There are, in fact, multiple ways to solve this problem.  From the complex to the simple.  I’ll share with you the three options that I believe could help solve this problem.  Could there be more?  Yes, this isn’t an exclusive list.  Could these options be combined, or modified, yes!  There is no definitive “right” answer, and each project has it’s own unique problems, contracting styles, management styles that requires owners/contractors to make decisions on how to monitor project progress.

Combine the risk tool with the scheduling tool.

First, let me through out an option that likely won’t work for managing and updating a schedule: combining the risk tool with the scheduling tool. Adding risk to the schedule and managing the risk and schedule seems like the most reasonable option (albeit more technically difficult) in terms of understanding schedule progress and projections. Also, having, maintaining, and creating mitigation strategies for risk I would argue is critical to managing a project properly.  By combining the project schedule with the risk tool during updates, turns a one-dimensional living document into a two-dimensional living document.  The risks adjust, move, change probability as often as the schedule needs adjustments, which is nearly daily.  As what-if scenarios, this is a great exercise.  However, using it as the official project schedule, just a nightmare.  I could see owners and contractors arguing probability and potential impact of events which get very esoteric very quickly in schedule projections.  One would create a much larger level of complexity likely having the consultants and lawyers charge more when things go awry.

Rolling Wave Schedules

Rolling wave schedules assumes that the level of detail decreases as you go out in time.  Time periods are established by the owner, where schedule detail is required to be broken into smaller pieces.  For example, within the next month, no activity longer than 3 days, within the next  3 months no activity longer than 2 weeks, within the next six months 30 days, after that 90-day activities allowed.  This follows the pattern of generally how we plan.  We have a really good idea what’s going to happen in the short term, and a rougher idea what will happen 6-12 months + from now.  It means that short-term plans are more accurate, and longer-term plans fall within a range.  I know for a fact Disney requires this method for their construction projects, and while I hated doing the work as the contractor, I have to argue it was much more accurate in representing the work on in the field and retained about as much accuracy as one could predict for activities 6 months out.  There are, of course, technical arguments for and against, and I’ll go over those in another post.  The goal here was to introduce the concept, and show that it is used successfully to manage construction contracts by complex owners.

Treating Risk like the Weather

In many contracts weather delays are required to sit on the critical path and a statistically predicted amount is allowed for each year. Why? Because we know weather delays happen, we don’t know when they are going to happen so owners require contractors to bid and keep in their schedule a certain amount of days for weather delays.  If no weather delays occur, these days become float, if more happens then you have to push out the date (no-cost delays).  This allows the contractor to bid and price in what these likely delays are, which is typically the cheapest way to price in the impacts, and is both fair to the contractor and owner.  Yet, we schedule the project like there’s going to be no problems with the site, drawings, owner-provided items, or subcontractors, labor, turnovers, contractor deliveries.  So why not bid likely risk-days into the schedule, just like many owners do with the weather.  In this case, you’d have separate owner and contractor separate risk days.  Owners could use statistical information on delays based on dollars, size, complexity, or use a risk register to generate a number of days for owner-related risks for that specific.  Similarly, during the bid process, the contractor could generate their own risk register (or statistical study) and generate their own number of risk days, and bid both the owner’s risk days and the contractors risk days.  You could have a fixed milestone, so the risk days are used for acceleration costs, or movable end milestone and the risk is used to offset overhead costs.  Unlike float, I would not recommend combining them into “project risk”.  The owner and contractor have their own unique risks and really should be treated and owned separately.

Conclusion

None of these approaches will necessarily solve the legalese, techno-schedule conversations or completely remove schedule conflicts.   Projects are complex and full of risks and the money involved can always make things contentious.   What this does help is remove the naiveite that you start with a schedule knowing exact date and times for activities 2-3 years in the future.  Whether you use a risk-days schedule or a rolling wave schedule (or combined) the goal is to create clearer concepts of how far future activities really fall within “ranges” of dates and do not fall within an exact date.

By aligning schedules more closely with reality, we can preserve them as genuine planning tools rather than documents of defense.  In the meantime, or during the process, ProjectControls.online can help everyone understand the schedule better, what changes have occurred, and what the project team needs to be concerned about no matter what the approach.

Leave a comment