Integrated Master Schedules (IMS)

It is a truth universally acknowledged, that a manager in possession of a project, must be in want of a project schedule (With apologies to Jane Austen). On large projects for the US government there is an "Integrated Master Schedule" (IMS). The IMS is often used as a report deliverable, and so is updated monthly for the customer to see it. I have found that the IMS is most useful as a working document. This is for two reasons: 1) it saves me all of the time to update the IMS for the customer because it's already updated for me, and 2) the IMS is recommended for a reason, and I try to take full advantage of it.

1937 Panama Canal schedule

My peak time using IMS as a tool was doing new product introductions for military landing gears. At that time I had several simultaneous projects, all requiring Department-of-Defense-compliant Integrated Master Schedules, which included a 14-point compliance check as well as a variety of metrics that defined the "health" of the IMS. I grew adept at building the schedules quickly, and began using them as my daily tracking tool as well.

Use as a Working Document

Once the schedule was drafted, using estimates from subject matter experts and previous experiences on my part, updating it was a daily or weekly task, depending on when I was learning new information. For example, I tracked some major structural components on the nose landing gear three times per week. I aligned the tasks in the IMS with how the supplier reported their progress to me. If the supplier gave me eight serial numbers worth of data, then I had eight separate summary tasks on my master schedule for that part number. Under each of those eight summary tasks, I would then have all of the various manufacturing tasks at the supplier's level of detail (or more-detailed as I asked questions on calls). I might have rough machining, heat treatment, finish machining, processing, painting, etc., plus repair and rework items when needed. When the supplier reported to me, I could see what they had told me previously and my baseline schedule, and I would adjust the start and finish dates for the current task based on what they told me for the in-work task, and all future tasks would pull in or slide out per their durations. This allowed me to use the latest information from the supplier, but not require me to trust their final delivery dates: they are often much less reliable than the dates of the in-process work.

When things go wrong, I would turn the original task into a summary and create a few new tasks under it. The first is "progress made before the problem", the remainder are "time to fix the problem" and "time to finish the task after fixing the problem". Without this, the IMS doesn't show why a task is suddenly late, and it's harder to track those "fix the problem" tasks if they're not explicitly on the schedule.

When it came time for the customer update, I would review the schedule, look at the finish dates, and adjust any risk reserves (see this later) or otherwise tweak durations to show a static delivery date if that was merited, or show them any slips or pulls-ins that happened in the past week. A few days before the schedule was due, I would also filter the schedule for any tasks that were supposed to be in-work or starting soon (filter on <100% completion and start dates up to a week in the future) and confirm that we were actually making progress on those tasks and/or ready to start them. Instead of reviewing hundreds of line items, I could focus on the dozen or so tasks that mattered.

Risk

Risk management is often difficult on a large projects: even when we use a defined risk capture process the results don't help the project. We might pull the whole team together, capture potential risks and their countermeasures and ideally the response plans and timing, and then that plan often ends up shut in a drawer somewhere. However, if we move those countermeasure plans to the master schedule then we are always tracking them as we review our week-over-week tasks.

In addition, any buffer or risk mitigation time that we put into the schedule (we should always have management reserve time) gets assigned to particular tasks that we see as high-risk, not to the very end of the schedule. When we have a task with associated risk-mitigation time, we don't just define the task at that longer time because then we've lost visibility on how long that task should take if you don't need the risk mitigation. Instead, we define the "actual" task for the time that it should take, and add a "buffer time" task as its successor, and all of the other successor tasks are connected to the risk-mitigation task. You track the task to its planned duration, and if it exceeds that duration, we update its finish date (expanding its duration) and shrink the duration of the risk-mitigation time, which keeps the start date of all successor tasks fixed. If the task finishes on-time or faster than planned, we zero out the risk-mitigation time and either take credit for it (pulling in our final delivery date) or increase the buffer available to a later task. All successor tasks do not move while we're within the boundaries of the risk-mitigation plan and only after we've used up the buffer does the rest of the schedule have to adjust.

An Example

Thanks to www.onlinegantt.com, I pulled together a quick example even though I no longer have access to Microsoft Project.

No projects were harmed in the creation of this example

This project has had some ups and downs. Item #6 forging manufacure is complete, so we were able to take credit for any remaining risk-mitigation time and zero out its duration. Hopefully there was some left, because then a machinist gouged the part during rough machining! Instead of rough machining being a single long task, now it's a summary for a collection of other tasks. We got through two weeks of machining before the issue, and now we're halfway through reviewing the situation to understand how we might repair the part. After that's done, another day to get approvals (always add "time to get approvals" to your schedules!) and then we're off to perform the repair and resume regular manufacturing.

Note also all of the various hints I left myself in this schedule: Although "NLG cylinder" looks really repetitive in this example, if I start filtering at any point I'll be very happy to have that information; I might have dozens of "rough machining" items that I'd want to distinguish. Supplier name, purchase order numbers, nonconformance numbers, part numbers, serial numbers, anything that can help the task be unique and make it easier to follow up on are all valuable to add to this file. If I were reviewing this schedule and finding "this week we're supposed to have the repair instructions", the filtered task should give me that information so that I can reach out to my repair engineer and say "Nonconformance # X is in your queue. This the gouged nose cylinder serial number Y from supplier 1. Is that still on-track to finish this week?" Don't force your future self to look up that information again - it's at your fingertips right now as you're revising the schedule!

Conclusion

During this heady time of IMS use, I was not the only one working with them. But my schedules routinely got better customer feedback, were more up-to-date, reflected reality better, and took less time to update than my peers'. It's because I put as much data as possible into the IMS and made it a working document, which saved me from making updates twice and put my critical notes all in one place. Happy scheduling!