Having created a useful project or programme schedule, how do you use it as a delivery tool?

Here’s the approach I have used successfully on several recent programmes.

Background

During the final delivery stage of a multi-year relocation and Change Management project, with a few weeks to go before moving ~800 people and their equipment between sites, I was managing the integrated programme schedule to confirm we were in a position to move on the planned dates (or not!).

The Steering Committee (SteerCo) and Internal Audit wanted reassurance (via a series of pre-move readiness meetings) that we would be able to move on the planned dates, to know that the Business and Stakeholders would be happy to move on those dates; and for the programme to take any appropriate action to enable this to happen.

Prepare

To enable this, I created a suite of intermediate “collector” milestones on the programme schedule:

• “People ready” to move (reflecting the completion of Change Management activity, both “Must have” and “Should have”)
• “Systems & Building ready” to receive the People ( both “Must have” and “Should have”)

I worked on the basis that in order to be in the “Must have” category, the absence of the deliverable had to be big enough to stop the move; otherwise it wasn’t really a “must have” but a “should have”. I made these intermediate milestones immediate predecessors of the first move (with any slack available between these and the first move date being explicitly shown as schedule contingency).  I obtained current information on forecasts and actual start/finish dates through weekly Workstream Lead (WSL) reports and regular 1:1 schedule review sessions, and updated the schedule with this information.

Monitor

I monitored the plan (and especially the critical path leading up to the first move) for the effect on the final deliverables of any updates. Each time I updated the plan with new information, I checked to confirm we were still on track to deliver the final deliverables on the planned dates, adjusting the contingency buffer if necessary.

In this way I spotted anomalies – for example, having updated the schedule with revised dates from weekly WSL reports, I noticed final delivery milestone had moved 2 weeks later than planned. Each WSL’s detail plan appeared to be on track in isolation, but taken as a whole programme (taking dependencies into account) the final deliverables were late.

Detect

My typical approach to finding the cause of an anomaly such as this is to trace the predecessors of the slipped deliverable, working backwards in time to find where the delay is ultimately coming from (usually this is from missing or outdated inter-workstream or inter-project dependencies, raising the need for greater detail or revised dependencies).

In the case of the example, I isolated the problem to the start of a technology Pilot, which in turn was dependent on an IT system becoming available following Technical Testing and User Acceptance Testing (UAT).

Re-plan, Recommend, Resolve

I then analyse the situation and propose some remedial options, in the case of the example these included:

• Removing the IT system from the Pilot scope (introducing a quality risk)
• Shortening the duration of the Tech testing before the UAT and Pilot (also introducing a quality risk)
• Combining the Pilot with UAT by selecting UAT users for the Pilot, killing two birds with one stone (recommended approach)

The programme team opted to implement the combined UAT / Pilot approach I recommended, bringing the programme back onto schedule. The approach for Change Requests is similar:

• Create a new version of the schedule (or insert new activities in such a way that they don’t affect the “real”, working schedule) to use as a “what-if?” schedule.
• Make the changes as detailed in the Change Request, making or breaking dependencies as appropriate.
• Assess the impact on the delivery dates, resource utilisation, financial forecasts, and make a recommendation to the programme director and ultimately the SteerCo to accept or reject the Change Request.

Result

As a result of using this approach:

• The programme was kept on schedule, to deliver on time;
• SteerCo and Internal Audit were reassured that the run-up to moving was in hand, as they were kept up to date on an ever-diminishing list of pre-move “must have” deliverables;
• The Go/NoGo decision on moving was taken in the full knowledge that: all “must have” deliverables would be in place on day 1; most “should have” items would be in place on day 1, and the missing “should have” items would become available on specific dates post-move.

In this way, the schedule was transformed from a collection of dates and coloured sticky notes on the wall into a dynamic tool with which to proactively manage programme delivery.

So that’s my approach to keeping a programme schedule on track, learned through training and experience. It this approach useful to you? How do you keep your programme schedules on track?

If you would like to have the benefits of a scheduling approach like this but would prefer not to get bogged down in the detail, The PMO Professionals can help. Why not take a look at our “Savvy scheduling” service, and if that looks interesting, perhaps get in touch?