How to create a useful programme schedule, and use it to keep delivery on the right track

If you are the PMO Lead on a strategic programme, charged with creating a schedule for the collection of integrated projects, how do you integrate the schedules of multiple projects into a single, useful programme schedule that concisely conveys time-related information? And how do you then monitor the delivery of the projects in the programme, acting as an early warning system for the delivery of the programme?

1. Why bother?

Any organisation that is changing (so that’s most of them then!) probably has a significant chunk of its attention and resources focussed on one or two strategic change programmes. Whatever the aim, these programmes will have multiple projects running simultaneously and will be consuming significant resources.

In such a situation, it is vital for you to be able to answer the following questions (amongst others):

  • When will we deliver?
  • What resources will we need?
  • If something delays project X, what will the effect be on project Y, and the overall delivery of the programme?

Too often, a schedule is created at the beginning of a change initiative, maintained and referred to for a while, and then quietly abandoned once it no longer ties up the reality of delivery, left to grow dusty hanging on the wall or tucked away in a drawer.

But a programme schedule should not just be a pictorial representation of what we wish would happen, or a rigid list of events to which the programme should slavishly adhere.

A well-built programme schedule can answer the above questions and more.

A useful programme schedule can and should be a flexible mathematical model of the programme’s activities that you can use to forecast potential problems, adapt to overcome those problems, and use to enable on-time delivery.

Sometimes the organisation will already be using a dedicated Project Portfolio Management tool that will help you to answer these questions. More often though, there will be no tool, and no organisational appetite to implement one – even for a significant programme. So, you will be left with the standard tools available to project managers – stand-alone Microsoft® Office and Project®.

In this situation, you could run multiple schedules linked to one resource pool. This sounds like a good idea, but in my experience the logistics can be clunky. It means that only one Project Manager (PM) at a time can have the resource pool open to edit, which stops all the others from changing pretty much anything in their schedules and soon becomes unworkable.

You could integrate project schedules into a single programme schedule by inserting them as subprojects of a master project. This also sounds like a good idea, but it doesn’t work well if PMs want to keep a version history of their schedules and use the “versioning by filename” approach. It can cause problems with broken inter-project dependencies when PMs delete and replace tasks in their individual plans, and the interrelationships between plans can cause tasks to move around so much that they become difficult to manage.

This article describes an approach I have used successfully on multiple occasions, based on creating and maintaining a useful programme schedule “above” the project schedules.

2. How to create a useful programme schedule

When I am brought in to a programme, it is usually because the realisation has just dawned on the organisation that the initiative is more than just a collection of projects, and needs central co-ordination. In most cases, at least some of the projects already exist, and their schedules are in various states of maturity according to the quality and diligence of the project managers.

2.1 What have we got?

I suggest that first you should review what already exists across the projects in scheduling terms (whether these are project schedules, task lists, or just brainstorming outputs).

If you are lucky enough to inherit a complete set of MS-Project schedules, don’t get too carried away! You will need to review the quality of these carefully rather than accepting them blindly. The quality of a given schedule is likely to be strongly linked to the skill levels and general thoroughness of the project manager who created it. To save yourself a lot of time, I recommend you use an automated approach to identify logical scheduling errors before you do anything else.

It will be easier for you to easier to integrate the project schedules (e.g. by copying and pasting blocks of tasks between schedules, or copying useful formulae, filters, views, etc. between schedules) if everyone is using any customised fields for the same purposes – you can help here by supplying PMs with a standard template.

2.2 Build

Next you can move on to represent summarised project schedules in the programme schedule. Here you are looking to capture the key activities and deliverables of each project that affect the overall programme delivery. This can be because they deliver products to another part of the programme (i.e. there is an inter-project, intra-programme dependency), or they produce intermediate deliverables. It is difficult to set hard and fast rules on how much to include; you need the programme schedule to be just detailed enough to enable you to track progress, but not so detailed that it is onerous and burdensome to maintain. If the PMs’ schedules represent day-to-day activity, your programme schedule should represent week-to-week or even month-to-month activity. You will be monitoring the PMs’ progress on typically a weekly basis, and you will be reporting programme to the Programme Steering Committee (SteerCo) on typically a monthly basis. As a rough rule of thumb, a useful programme schedule will probably contain about a tenth of the number of items in the PMs’ schedules.

There may also be workstreams that perform a shared service across multiple projects in the programme (e.g. a software testing team that test the products of all the projects in the programme, or a specialist office move team that will relocate people to all the locations in a fit-out-and-move-programme). You may represent these activities as discrete workstream schedules, or as sections within each project schedule (the latter makes it easier to see how the work goes towards a deliverable).

I like to talk through any existing project schedules with the relevant project managers (PMs) and workstream leads (WSLs – people leading teams that carry out work or provide services across multiple projects, e.g. design, testing), entering their key activities directly into my MS-Project® programme schedule (copying and pasting where possible and appropriate), reviewing and challenging effort estimates and dependency relationships as we talk.

Where there are no plans at all yet, you can establish a work breakdown structure and rough sequencing by referring to any process flow diagrams that may have been produced by Business Analysts (BAs), or by holding planning workshops to identify the key activities and relationships. This is not about planning or scheduling the activities in time, this is more about creating or developing a work breakdown structure and capturing information about the items in it. MS-Project’s hierarchical task grouping capability presents an excellent framework for doing this and it saves time to do it directly in the scheduling tool. The important thing is not to jump to dates and durations at this stage. Once all the project scope is represented as tasks, you can go back and link project tasks together with dependencies, to form a sequence and schedule for the project within the programme schedule.

2.3 Integrate

2.3.1 Dependencies

Next you can identify the links between the projects. You can get the PMs to send their schedules round to the other PMs for review, but in practice I find this rarely gets done effectively. The best approach I have found is to hold a planning workshop or series of workshops. Get each PM in turn to talk through their schedule; get them to explain what is being delivered when; who is to work on which tasks, etc. This process can feel a bit wasteful of time, as each PM spends most of the session listening to all the other PMs present their schedules. However in my experience it is the single method that is the most likely to produce the moments when PMs realise that several of them need to use a unique resource at the same time, or that Project A needs to use deliverable X before Project B has delivered it. Once these anomalies have been identified, you can get the PMs to work together to agree how each one will be resolved.

This session (or series of sessions) will also enable you to identify the deliverable dependencies between projects. You can then represent these in the programme schedule with dependency links between the project tasks, and maybe in a dependency register if you think that would be helpful. The most important thing to get out of all this is the knowledge of what is dependent on what, and an agreement between the affected PMs on how the dependency will be managed (at the very least, the PM creating the deliverable needs to keep the recipient PM informed of the deliverable’s status).

Where a programme has several projects and/or workstreams producing deliverables that all aim at a series of Go Live events, I like to group these together with what I call “collector” milestones, in both “must have” and “should have” flavours. For example in the case of a fit-out-and-move project, (amongst other things) the building needs to be ready to receive the people, the IT systems need to be ready to work the day the people move in, and the people need to be ready to move. So we can have three collector milestones: “Building ready”; “IT Systems ready”; “People ready”, each with a “must have” and “should have” variant. Make the “must have” milestones immediate predecessors of the first move or Go Live, with any slack available between these and the planned first move or Go Live date being explicitly shown as schedule contingency. Then make all the intermediate deliverables predecessors of a “must have” or a “should have” milestone. To be a predecessor to the “must have” milestone, the absence of the deliverable must (on its own) be big enough to stop the move or Go Live; otherwise it isn’t really a “must have” but a “should have”.

“Should have” deliverables are effectively those that can be delayed until after Go Live.

2.3.2 Resources

The planning session(s) will also enable you to identify any critical “bottleneck” resources who are required to work on several projects at the same time. If the project schedules are of sufficient quality, the PMs really should be able to identify and resolve any resource over-allocation within their own project. However, they may not be aware of any over-allocation resulting from demand for the same resource arising at the same time across multiple projects. There are nearly always some of these bottleneck resources; they are often subject matter experts who have deep knowledge of the way the business works, and who usually also have a “day job” in operations. If the schedules have been properly “loaded” with resources, dependencies and constraints, you should be able to work with the PMs of the affected projects to re-sequence tasks to remove or at least reduce any resource over-allocation between projects to arrive at a (relatively) resource-levelled, useful programme schedule.

2.4 Agree & Baseline

At this point you should circulate the schedule to all the PMs and stakeholders for review and agreement.

For this review, project teams usually need considerable level of detail, whereas senior stakeholders usually prefer much less detail, with just the key milestones and activities shown. You can satisfy both requirements from one live data set using customised Gantt chart views, and you can circulate extracts to people without MS-Project software using PDF Gantt charts with dynamic labels.

Once all stakeholders have agreed to the schedule (which they should be able do because they were involved in creating it):

  1. Set a baseline (saves a reference set of dates against which to assess progress and monitor changes)
  2. Set deadlines on the key deliverables[1] so that a warning will appear if any of them are delayed beyond a critical date

3. How to keep the schedule on the right track

Once the schedule is agreed and baselined, you can keep it on the right track by keeping it updated with progress information from PMs and WSLs, looking for any changes to the key delivery milestones, re-planning options to overcome any changes that result from delays or change requests, and regularly circulating extracts or summaries of it to interested parties.

3.1 Communicate

The schedule will need to be regularly communicated, both to the project teams and the stakeholders.

Project teams are usually very delivery-focused, so they find it helpful to have plenty of detail on what’s overdue and what’s coming up (either due to start or due to finish) over the next few weeks; you can prepare time-boxed schedule extracts for circulation and review (e.g. in team meetings) by applying compound task filters to show the tasks of interest.

Senior stakeholders on the other hand have a much more strategic viewpoint and usually prefer a “road map” with much less detail covering a much longer time period (to assess overall progress towards delivery deadlines, and integration with enterprise milestones).

As with the initial communication for agreement, you can satisfy both requirements from one, live data set using PDF Gantt charts with dynamic labels generated from customised Gantt chart views.

3.2 Monitor

The next step is to keep your summarised plan updated with latest forecasts and actual start/finish dates, through regular reports from, and meetings with, the PMs and WSLs. As your plan will have less detail than the PMs’ plans, this is probably not about the detail of work complete and work remaining on specific tasks. This is probably more about the question “are we on track to deliver product X by date Y?”. It is good to talk to both PMs (responsible mostly for managing the work) and WSLs (responsible mostly for getting the work done, alongside possibly competing assignments for other projects) as sometimes they will have different views on the same tasks.

A good way to start the conversation is from an automated RAG rating (arrived at by comparing baseline start and finish dates with latest forecast start and finish dates and with the current date, and applying some simple rules), together with a coded commentary on each task that could help to explain why an item may be Amber or Red. This is a good place to start because it is based on hard data.

3.3 Detect

Keep an especially close eye on the critical path leading up to key deliverables. Each time you update the programme schedule, check to ensure that key deliverables are still on track and within deadlines.

Sometimes you will find that the final delivery milestone will be delayed even though the individual project and workstream schedules appear to be on track. You can find the cause of a forecast delay by working your way through all the predecessors of the delayed delivery either manually or more efficiently by <using a macro>.

Often the cause will be missing or outdated inter-workstream or inter-project dependencies, raising the need for greater detail or updated dependencies. Sometimes one task will have been scheduled as being dependent on another, when after consideration the dependency turns out to be a “should have” rather than a “must have” and so you can remove it.

3.4 Re-plan, Recommend, Resolve

Once you know the cause of a delay, you can analyse the situation further and recommend some remedial options. These might include, for example:

  • Maintaining the Go Live date for the most important deliverables by agreeing to deliver less important (“should have”) items after the Go Live date, i.e. on “day 2”[2]
  • Adding resources to the delayed task or other tasks to get the work finished faster and deliver it sooner (although this does not always work; for example nine women cannot gestate a baby in one month!)
  • Resequencing tasks to enable everything to be delivered on time

So that an informed choice can be made between these options, you will probably need to model what the schedule looks like for each of your possible scenarios. You would also do this to model the effects of any Change Requests that are raised. To do this:

  1. 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.
  2. Make the schedule changes as detailed in the proposal, making or breaking dependencies as appropriate.
  3. Assess the impact on the delivery dates, resource utilisation, financial forecasts, etc., and make a recommendation to the programme director and ultimately the SteerCo.
  4. Once the decision is made, implement it in the schedule, update the baseline data for the affected tasks, and continue to monitor progress.

4. The Result

Using this approach:

  • Will give you an early warning system to alert you if the programme is drifting off schedule, and enable you to take steps to keep it on track to deliver on time.
  • Your SteerCo will be reassured that the run-up to Go Live is in hand, as they will be kept up to date on an ever-diminishing list of pre-Live “must have” deliverables.

Consequently, your useful programme schedule will not be just a collection of dates and coloured shapes on the wall; instead it will be a useful, dynamic tool with which to proactively manage programme delivery.

If you want more detail on the nitty-gritty of how to set things up in MS-Project®, take a look at some of the related posts below.

If you want to see what sort of difference this kind of approach can make in practice, take a look at this case study.

If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not book a free consultation slot to talk to us about taking care of it all for you on your next big project or programme?

5. Related posts

6. Acknowledgements

  • Microsoft, Project and Project Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries

[1] To set a task deadline, in MS-Project 2016 double-click on the task name in the Gantt chart table, which brings up the Task Information dialogue box. Go to the Advanced tab, and enter a calendar date in the Deadline field. This date can be displayed as a graphical symbol on a Gantt chart. If the finish date is delayed beyond the deadline date, a warning symbol will be displayed in the “indicators” column of the Gantt chart table (the leftmost column on the default table).

[2] Sometimes deliverables that are “must have” for the Go Live date are referred to as “day 1” deliverables (i.e. they are needed from “day 1”), and those that are “should have” are referred to as “day 2” deliverables (i.e. they are not needed for day 1 but will be needed very soon afterwards)