How to create a useful programme schedule

How to create a useful programme schedule

How do you integrate the schedules of multiple projects into a single programme schedule that concisely conveys time-related information? This is the approach I have used successfully for several programmes.

I was brought into a programme which had only rudimentary programme spreadsheet-based plans, and which was therefore unable to forecast how delays in one part of the programme would affect other parts of the programme, or to assess the potential impact of change requests. Senior stakeholders needed a programme “road map” (to assess overall progress towards delivery deadlines, and to obtain some guideline forecasts for the annual budgeting cycle), and the programme director needed a detailed view of the activities leading up to delivery.

Purpose of the schedule

A programme schedule should not just be a pictorial representation of what we think will happen, or a rigid list of events to which the programme should slavishly adhere. Instead I believe it can and should be a flexible model of the programme’s activities that can forecast potential problems, be adapted to overcome those problems, and be used to enable on-time delivery.


Where they already existed, I used task lists and brainstorming session outputs as a starting point. I developed these by meeting with project managers (PMs) and workstream leads (WSLs), capturing their thoughts on the key activities of their projects directly into Microsoft® Project® (MS-Project), challenging duration estimates and dependency relationships as we worked. I refined the resultant draft schedules using stakeholder input before getting them agreed by all parties and baselining them.

Where there were no plans at all, I either held planning sessions or translated process flow diagrams prepared by Business Analysts into MS-Project plans, cross-linking these with dependences into an integrated and resourced programme schedule, with the critical path identified and highlighted.

I also worked with contributing PMs / WSLs to standardise elements of their plans (e.g. use of custom MS-Project fields) for easier integration into a programme schedule.

From this programme schedule, I prepared resource and financial plans for budgeting as required, custom filtered views (missed milestones, items due to start or finish in the next four weeks, etc.) for progress tracking, and highly summarised “road maps” for senior stakeholders.

I kept the schedule updated with progress and with the outcomes of approved Change Requests; I regularly reviewed forecasts against the schedule baseline to identify potential slippage; and prepared “what-if” plans showing the impact of proposed changes.


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

Under this approach, the Programme Manager has a good forward view of the critical path to delivery (and the potential pitfalls along the way) and the Programme Board has a good overview of progress achieved so far, and the activities still to come.

But what about when things change? What do you do then? More about that in a separate post.

So that’s my approach to creating a useful programme schedule, learned through training and experience. Is 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, Pragmatic PMO can help. Why not take a look at our “Savvy scheduling” service, and if that looks interesting, schedule a free 30-minute consultation to discuss how we can help you?

® Microsoft and Project are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Author: Ken Burrell

Ken Burrell is a Programme and Portfolio Office (PMO) Professional, who through his company Pragmatic PMO makes targeted improvements to PMO practices to add value to Projects, Programmes and Portfolios. He provides senior management with the analysis they need to make decisions, and gives project and programme managers the support they need to deliver solutions.

5 thoughts on “How to create a useful programme schedule”

  1. Hi Ken! Thanks a lot for this post! It helped me to clarify the approach I’ll to use in the programme I’m working in. If possible I would like to hear your opinion about one thing:

    We’ll have more than 15 medium-sized projects running at the same time and I was wondering about which tasks should I include in the programme’ schedule. Did you update it manually checking their schedules one by one or did you integrate PMs schedules into one big programme master schedule receiving external updates?

    1. Hi Eduardo!
      Glad you enjoyed the post and found it useful.
      The approach I would recommend depends mainly on the organisation’s maturity in terms of both PM capability and systems / software, and the nature of the interfaces between the projects that make up the programme. In most cases the planning can be done on a top-down or bottom-up basis, or a cobination of the two. The main options (in order of increasing complexity and automation) are:

      1. Create and maintain all the project schedules inside the programme schedule (i.e. no separate project schedules, just one programme schedule file that contains them all).
        Create and maintain the project schedules as sections within the programme schedule, summarising as appropriate for various audiences. This works well if the constituent schedules are fairly simple, or if the PMs need extensive help from the PgMO in keeping on top of schedule maintenance, or if there is a high degree of resource sharing across the projects that make up the programme. This approach does not require the use of programme level software that shares resource pools across multiple projects.
      2. Create and maintain all the project schedules separately, and maintain a separate programme schedule that summarises them.
        The approach here would be to create the project schedules, create a programme schedule that summarises the project schedules (representing a project in the programme schedule with maybe 10% of the number of tasks that were in the project schedule), verify that the dependencies all work and then baseline all the schedules. PMs manage their own schedules, keeping the PgMO up to date on progress via regular status reports and/or meetings. The PgMO makes manual updates to the programme schedule (these are small due to the smaller number of tasks in the programme schedule). This approach works well if the main links between the programmes projects are via deliverables (rather than resources), if there is likely to be little variation in the structure or scope of the programme’s constituent projects. This approach also does not require the use of programme level software that shares resource pools across multiple projects.
      3. Include the project schedules as subprojects of the programme schedule.
        The approach here would be to create the project schedules, combine them into a programme schedule as a collection of subprojects with a shared resource pool, carry out resource levelling across all the projects and then baseline all the schedules. This works well if the links between project schedules include inter-project resource sharing as well as deliverables from one project to another. This approach requires bi-directional communication between project and programme schedules (and resource pools), and things can get tricky if one PM wants to make changes to their schedule when another already has the resource pool open and hence reserved. PMs need to go into their schedules, make their updates and then exit (rather than having their schedules open for editing all day). It would work better in a medium maturity environment.
      4. Make use of enterprise level, integrated project scheduling software.
        The approach here is to create project schedules using a shared resource pool, level the schedules against the shared resource pool (which takes all other project activity into account), and create a programme schedule that summarises it all. This I guess is the ideal, but it depends on resource managers keeping their resource pool availability accurate and up to date, and on project managers keeping their schedules up to date and respecting the availability of the resource pool. So it works best in organisations of higher maturity in terms of both their project management approach and their systems and software.

      I hope that answers your question, and gives you enough information to identify the best approach for you, your programme and your organisation.
      Regards, Ken

  2. Ken, I appreciate your support. I believe the 2nd option will suit better with my reality once the projects will not share resources, there are well defined and limited tasks for each project with minor differences and the interfaces between projects are based on deliverables. We already started the weekly check points with each PM and I believe this dynamic will work to gather the status updates.

    These 4 scenarios were really helpful to picture out different scenarios and I agree the choice will depend on the level of maturity of each organization. Programs are challenging due to the risk each project represents in the achievement of overall outcomes but consistently tracking the progress of the projects might help to mitigate this risks or at least support decision making process.

    I’m really thankful for your attention!

    1. Eduardo, you are most welcome.
      Here are a few more tips that you may find helpful for pragmatic programmes:

      • Identify the critical path through the programme schedule (as well as the critical path for each project), and pay special attention to monitoring the items on it. This protects the timeline for the programme as a whole, as well as the timelines for the individual projects.
      • Manage Risks, Issues, Assumptions and Dependencies or Decisions (i.e. RAIDs) at programme level, using registers that contain all the RAIDs from all the projects in the programme, as well as the programme itself. This makes it easier to spot whether the same problems are being reported across more than one project, or whether problems arise across projects from the same causes.
      • Standardise reporting across the programme, using a standard reporting format for each project and a similar format for the programme to report on itself. This simplifies and speeds up report preparation, and ensures that the projects are reporting on the same things in the same way, making it easier to compare projects.

      I wish you success with your programme,

      1. Absolutely Ken!

        These are good tips.

        I’m already monitoring the risks and issues in a programme level. I created specific IDs for each risk/project in the risk matrix in order to set the correlations between them. I didn’t know the RAID acronym/approach and I’ll take a look on that. I’ve often approached risks and issues but not assumptions nor decisions.

        I’m also using standard reports and it is planned to use the same format for the projects when they start.

        Thank you!

        Eduardo Lagares

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.