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 an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?
® Microsoft and Project are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.