Programme Planning: Some home truths before we set out…

Those of you following the PMO Programme will know we’re still in the early days of bringing structure and control to our programme. Not untypically, the programme has been up and running for a couple of months already and we’re only just getting the PMO together, so some rapid catch-up and positioning is required. We’re about to start tackling one of the key tools for managing our programme – the programme plan. But before we get started, let’s go right back to basics and clarify some basic aspects of the programme plan.

This post covers:

• Plan or schedule: setting the terminology and mindset
• Planning levels: how many, what for?
• The changeable nature of plans and how to manage that change

Plan or Schedule?

Let’s get this one straight first.

A schedule is ‘who, what and when’. A schedule is a Gantt chart. A schedule is a list of activities, resources and dependencies that can be optimised to show the most efficient way to carry out those activities. A Microsoft Project ‘plan’ is a schedule. A schedule is part of a plan, but a plan it is not. End, as the youth of today would say, of.

A plan is a description of how we’re going to get from where we are to where we want to be. Yes, it needs a schedule to make sure things get done in a sensible order, but it’s much more than that. A plan understands the organisation it’s working in. A plan understands the assumptions made and the risk appetite of the business. A plan not only includes the who, what and when, but also shows:

• Tolerances, and how we’re doing against them
• Assumptions, and which are holding true
• Risks, and what we’re prepared to do about them
• Deliverables (or products if you will), and what they are
• Resources, and what skills they have
• Costs, and how we’re doing against forecasts
• All the ‘necessary bureaucracy’ stuff – checkpoints, quality gates etc.
• Dependencies between projects and between the programme and the outside world

A plan is not a single document – if it was, it would be time consuming and unwieldy to produce, difficult to comprehend and almost impossible to maintain. A plan should be seen as a collection of documents (which may consist of schedules, RAID logs, product descriptions etc.) An effective plan is one which ties each of these components together in a consistent and coherent manner, allowing views of the plan to be taken that meet the needs of varying audiences but stem from the same, single source of programme data.

Planning Levels

When people talk plans, you’ll hear them bandying about terms like ‘level 1’, detailed plans, roadmap, ‘level 3’, plan on a page, programme plan, workstream plan – the number of different type and level of plans is apparently endless.

For the purposes of The PMO Programme, there will be three levels of planning, each aimed at specific types of audience and each with a distinct job to do. These levels are:

• Level 1: Plan on a page
• Level 2: Major areas of activity and key deliverables
• Level 3: Workstream or project plan

I know some plans have more levels than this (many in the world of Agile development routinely produce five level plans to cover individual iterations and releases), but remember this is the programme plan. At some stage the programme PMO has to hand control to project managers (who, after all, are the people who actually know what they’re going to do) and if the individual teams on our programme wish to break their Level 3 plans down again then that’s fine by me – as long as they do it in a way which maintains the integrity of their Level 3 plans and their integration across the programme.

Ok, so what are these levels for?  In summary, and using the schedule as a basis for defining the content of the plan :

Plan Level	What does the schedule show?	Who’s it for?	Who produces it?
Level 1	‘Plan on a page’-          Major deliverables and milestones shown in a way that makes sense to the business sponsors	The Senior Responsible Officer (programme sponsor)The Programme BoardThe wider organisation	The PMO in conjunction with the Programme Manager
Level 2	–          All major activities and deliverables that contribute to achieving the programme’s objectives.-          All dependencies between (not within) projects and between the programme and external bodies.	The programme management teamThe programme team	The PMO in conjunction with the project/workstream managers and the Programme Manager
Level 3	–          All deliverables required to complete the programme	Workstream/project managersTeam members	The project/Workstream manager in conjunction with the PMO

These three levels enable ownership and handoff to be clearly identified:

• The Level 1 plan is what the programme manager will carry around at all times, to describe the project to stakeholders
• The Level 2 plan allows the PMO to ensure the totality of the programme has been considered and all dependencies have been fully articulated and are being managed
• The Level 3 plan allows the workstream/project managers to manage delivery and report progress/exceptions

Another key thing to remember is that these are not separate plans. They are views of the same plan and there may even be more than one view of each level depending on the precise target audience. Because we’ve declared one of our driving quality principles as a ‘factual approach to decision making’ it is incumbent upon the PMO to ensure that the information presented in each plan is consistent, coherent and comes from a single, undisputed set of facts – in other words there is only one version of the truth, and it’s the truth set out in our programme plan.

The plan’s a best guess – embrace the change.

My programme manager wants to see the whole of our 18-month programme planned in detail. Only then can she be truly in control. My programme manager requires some education.

She needs to realise that a plan is a best guess at what needs to happen and how it needs to be done. Even with a highly experienced team and reliable metrics, it’s still an educated guess at best. A project is a ‘unique endeavour’ after all, and a large programme such as ours is a number of unique endeavours with a complex set of interdependencies, all being carried out in an organisation that’s unused to this degree of change. Chances of getting it right first time are slim at best – and we need to recognise this in our approach to planning. To satisfy my programme manager’s need for detail and assure her that I’m in control of the plan, I need a way of:

• using the Level 1 and Level 2 plans to make sure ‘the big picture’ is maintained
• showing her the detail we can be most sure about
• maintaining this level of detail without descending into ‘planning hell’

In outline, what I propose we do is this:,(and remember we’re not starting with a clean sheet here – some of our projects are already up and running):

Set an initial baseline:

1. Develop the Level 1 plan to show the major deliverables and milestones that make sense to the business sponsors and stakeholders
2. Identify the major deliverables that contribute (or ‘roll up’) to the Level 1 plan, based on whether or not those deliverables actively enable the programme’s objectives. (Current plans and the project inventory will help with this)
3. Use the deliverables identified in step 2 to develop an initial Level 2 plan
4. Use the Level 2 plan to develop/confirm the Level 3 plans for the next three months only
5. Use the Level 3 plans to do some ‘bottom up’ cross checks against the Level 2 and Level 1 plans, which may then need to be amended

Implement a regular planning cycle:

1. Regular (in our case weekly) updates to Level 3 plans are used to monitor progress and identify exceptions
2. Changes and exceptions to Level 3 plans are used to change (or invoke a change request against) other Level 3 plans and, if necessary, the Level 2 plan
3. Monthly planning sessions are held at which:
   1. Successes, exceptions and lessons learned from the last month are discussed
   2. The Level 3 plans are developed in detail for another month, to maintain a rolling three-month detailed plan
   3. Bottom up changes to Level 2 and Level 1 can be identified and discussed with the Programme Manager
   4. Level 2 and Level 1 plans can be updated as required (subject, of course, to tolerances and change control as require)

In short, we are:

• Taking a whole-programme view at Level 1 and Level 2
• Updating Level 3 plans on a weekly basis and using these to report progress and deal with exceptions against the plan at all lelvels
• Maintaining a rolling three month Level 3 plan through monthly planning sessions – learning as we go and not trying to plan all the detail up front

The above covers some of the basics that will underpin our programme planning. We’ve not yet  covered areas like how the plan is documented and presented, what tools we’ll use, how plan change control works, dealing with ‘top down’ changes etc. but I think that’s enough for now – we’ll start to tackle these and many other issues once we’re up and running.