Programme Management Uncovered – Part 4

When will things happen?

Normal practice is to tackle this at two levels – first via a High Level Roadmap, setting out the big picture and the key milestones and target dates, often with the key dependencies. Ideally this should be on only one or two pages so that senior management can visualise and control the programme – see attached POAP (Plan on a Page).

This plan and timeline will normally come from the project board, sponsor or steering group, and therefore only needs to be developed and validated.  There is significant merit in getting the Board, steering group and/or the programme team to participate in this process as it will provide a better result and generate some real ownership in the programme team.

There are many examples of what this looks like and I have shown a few in the attachments. Most are quite formal, as they should be, but they can also be tailored for the organisations to make them more effective. I remember one from a programme 2/3 years ago, which worked really well, which had the headings:

Making it essential     Make it ready      Make it happen     Make it stick

My advice on a really smooth way to get to the detail required, is to work through what I call the “middle step” using a tool called “Planning Matrices”.   An example of which is set out below.

Objectives Activities Outputs Benefits– Tangible or otherwise
Develop and agree workstream planAgree plan and “AS IS “ starting point

Assess current state

Workstream plan with activities, milestones, resourcing, dates Workstream plan with activities, milestones, resourcing, dates Strong starting point

Ideally this should be prepared as a team effort with each one run by the relevant workstream lead.

Then the items in the second column (activities) are transferred into the detailed plan, linked to owners and resources, elapsed time required estimated, any dependencies attached, and both start and end dates estimated.  In my experience, the key is to produce an early draft, circulate it for review and links, before finalising. Sometimes a number of iterations are required.

A good example of a programme plan with multiple projects/workstreams is attached.

It should also bring out the dependencies and include contingency time for unexpected matters or delays.   Typically tools such as Microsoft Project or sophisticated Excel templates will be required for this task.

This can be a tedious, rather dull and seemingly pointless task which many people would rather not do.  However, remember the sayings “If you fail to plan, you will plan to fail” and “Perfect planning prevents pathetically poor performance”.  So programmes must plan and depending on the complexity of the programme, the number of different functions involved, the number of dependencies, etc the more detail and fine tuning is required.

If there is any suggestion of fixed price contracts or time penalties for late completion, these will drive this need for a detailed plan even higher.

I have mentioned Dependencies a couple of times in this section, and wanted to re-emphasise how important it is to recognise especially the large dependencies – you can imagine building a house where there is a certain order to planning, foundations, walls, roof, fitting out etc and it is the same with programmes and projects.  If the big items are not identified and logged on the “critical path” then the plan will not materialise.