Programme management is the essential vehicle of organisation change and that is at least in part responsible for the awful confusion surrounding the word programme. Here are a few words to clarify before offering some essentials for ‘How To Manage A Programme’.
First is it program or programme? Well in British English a program runs on a computer and people deliver a programme of change. In the rest of the world program covers both. I’ll use the British English spelling for the rest of these thoughts.
The definition of what is a programme is a thorny issue. Mostly because people who write guidance gain their experience as suppliers and so gave project the definition they did so they needed to say something is different about programmes. A difference that justifies a bigger fee perhaps?
The published definitions then pretend there are differences where in reality there are not. So let us be clear. In some circumstances, a programme manager has a quite different role to a project manager. In most circumstances, most of the control needs of a programme are identical to the control needs of a project because a lot of programme control is just the sum of the controls of the projects.
The APMBoK 6th Edition says one bit well “Whilst it is convenient to pigeon-hole activity into one of the three dimensions of project, programme or portfolio, the reality is that these concepts are fluid and overlapping. Experienced practitioners should be able to draw upon techniques from all three dimensions in order to manage each unique package of work.”
The Big Project Programme
Some programmes are big projects. A big project type programme is one where multiple projects create outputs that are integrated into a final solution.
These types of programme typical depend on all the project’s outputs being integrated to deliver the final output. In this case omission of an output invalidates the final integrated whole.
A programme to build an aircraft carrier or an oil-field fits this definition. These programme managers DO NOT have responsibility for the flow of benefits that come after technical activity delivers products.
Some programmes are collections of related projects where the final solution is the most beneficial mix of outcomes. The subtraction of a project’s output simple changes the overall result not invalidates it. These programme managers may have responsibility from idea to steady state flow of benefits in a new habitual ‘future state of business as usual’ – of course by the time it is new habit it is no longer ‘future state’.
The Text Book Definition
This last description, when stiffened with some bookish vocabulary might be something like “A collection of projects and other activities managed together to bring about a benefit not otherwise achievable”.
I’m going to guess rather unscientifically but based on long experience that it probably applies to less real-world programme managers than the first definition that equates to “all the work to deliver a contracted result to a client (and then I/ we are done)”. For a start all engineering and I’ll speculate most IT programme managers have the duty that ends with ‘deliver output’ not create benefits flow.
How to Manage a Programme
The above dichotomy creates something of a challenge for some parts of the answer to “So, just how do you run a programme?” but not to all the parts of the answer. I’ll deal with the common parts first.
A classical role definition for a project manager says words to the effect “creates a defined output within constraints of cost time and performance (CTP) targets”. If this is true then the programme manager’s job includes creating the environment and procedures where project managers know what their three CTP elements are. In both of our definitions of programme, the programme manager role includes coordination of project deliveries across the (potential) need to integrate outputs and the sharing of resources.
Project and Programme Control
If a project’s control system is the templates, events, roles and procedures by which decisions are made then a programme’s control system is a common set of templates, events, roles and procedures.
Commonality is to promote both aggregated reporting and swapping people around. Running a programme should mean imposing a governance structure that harmonises project controls as well as recognising consistency of result is the target not consistency of process – that’s just a default start point.
Aggregated controls include allocation of the resource pool, creating the baselines, reporting status, holding risk reserves for project’s unknown unknowns and managing common risks (known unknowns), administering the change and configuration management arrangements and probably also the admin, logistics, travel, minute taking and 1001 other support activities.
The sole purpose of the control structures is to identify when goal or intended path to goal should change and take adaptive, perfective or corrective action. Control is only present when there is conscious decisions leading to action (or conscious inaction). We could diverge here into the qualities of good leadership and management but I won’t.
Within the list above was one item that might not belong there; from the ‘uniform’ perspective at least.
I hope that any project manager overseeing a project team building project deliverables – physical or intangible, well understood or beyond the state of the art etc – appreciates that each work-package should be conducted using the best suited product development life-cycle and the best suited control regime. That might be one that is predictive or one that is reactive. So the programme manager must appreciate the specific needs of the projects and of the affect the programme type implies. Are we ‘big project’ or best benefits?
Benefit Inclusive Programmes
If the programme type is ‘best benefits’ then the programme structure when described will sound very similar to any agile method.
Programme management text books have described iterative development approaches for a very long time. Managing Successful Programmes uses the French word tranche where Scrum uses ‘sprint’. The mechanics are close to identical even if the mind-sets are very different.
A benefits led programme has a profoundly different character to a ‘Big project’ programme because benefits ONLY occur when behaviours of people are changed.
When the programme manager’s role is deliver a programme that includes bringing benefits into steady-state flow then the programme’s foot-print expands to be the operational managers and staff whose future working practices must be amended.
Future Operational Behaviours and Attitudes
The creation of behaviours and attitudes is a very different undertaking to building warehouses, writing marketing materials or welding steel.
Firstly people generally react negatively to the prospect of change but come around over time after opportunity to mourn what is lost. The notion of “change is coming, yes its unfair but it’s still coming” has to be shared. The earlier it is shared and the more viscerally, visually then the sooner the adjustment cycle can start and the sooner Shock Anger and Resistance can be overcome leading to Acceptance and eventually Helping (in total SARAH).
A visceral description of an end-point is ‘Vision’. Vision is the result of combining Mission, Values and Market-place threat and opportunity. The total may often be correctly called a Wicked Problem (Horst Rittel) or a ‘Mess’ (Russel Ackoff) or political reality (the rest of us!)
The Japanese word for circulating or socialising a change’s impending arrival is nemawashi (根回し). Start socialising the end-point’s visceral, visualized description early and support the SA (Shock-Anger) process until the R starts to dissipate then embrace the AH.
End-Points as Exit Tests
My preferred method for forming and cascading Vision is to frame ‘Exit-Tests’ that borrow from Use-Case, Business Driven Development and Test Driven Development best practices. To borrow the ‘Given context, when event, then outcome’ which suits output orient projects my structure is:
As [ role ] I will inspect [ business behaviours in operation] , in [ context] on [ date] . Lets try an example:
As Head of Operations I’m coming to inspect the despatch of customer orders from our new warehousing facility on the 1st of October this year.
A crucial property of an exit-test is that it must be within the will, skill and ‘gift’ of the person framing it to make it happen because all subsequent cascaded contradictions between intent and committed support will escalate back to the framer to take action to resolve. We might say this is the mechanism by which Servant Leadership (Greenleaf) is made meaningful in programme sponsorship.
Decomposed or Back-Cast
Note the specification of date but not of the detailed quality criteria. Most investment decisions and market-sensitive activity is bound to a date from the start but all other factors are ‘discovered’ and emerge as we proceed. Recall to that cascading an exit test imposes accountability on the framer to be able to make it happen so the date included ‘belongs’ to the person cascading the desired end-point.
The back-cast enablers must include a host of operational behaviours – e.g., the warehouse is stocked, the order taking process works, there is outbound transport and there are people type results – e.g. sufficient numbers of available trained staff. These enablers are further decomposed or back-cast to milestone descriptions which are sufficiently granular to be given to project managers to fore-cast plan to meet them.
The staffing milestone might say 100 staff in 4 cohorts of 25 trained in systems x y and z and rostered for 24 x 7 operational service hours. Within the resolving project there might be a training work package that might then use PRINCE2 template A26 to say “achieves a score of 75% when audited for competency by the shift supervisor in the ‘model-office’ test environment”.
Exit Tests are Planned Right to Left
The hierarchy of exit tests starts ‘at the right hand side’ of the timeline and back-casts to today. The specifications respect the targets of key importance at the level of specification. The decomposition (back-casting) ONLY selects enablers (solutions) that meet the inherited constraint. That is the “you can’t because any fool knows it takes longer than that” iron-triangle argument is banished by “It is your proposed solution that is the variable. Find an alternate solution that does meet the business need”.
Within programmes embracing complexity the need to plan is constantly close-by. Only in highly predictable and stable circumstances (like mechanical engineering implemented by robots) can all planning and design be realistically be undertaken at the start. In all other cases the involvement of complexity and or people mean plans need to be adjusted for unknowables and for mistakes.
There is more I could describe but the basics are covered. Lets review them. The basic answer to “How do you manage a programme” is
- Cascade a vision of the end point and support the participants to design a route to success.
- Impose a common set of processes to report progress, change and uncertainty into the decision-making duties of the sponsor’s chain of command.
- Ensure variance in actual or desired performance leads to adjustment of plans.
- Match the controls, particularly development lifecycle choice to the nature of the result required from each work-package. Expect individual projects to each use multiple methods.
- If benefits are in scope ensure sponsorship and leadership team encompasses operational behaviours.
- If benefits are in scope use nemawashi to socialise the SARAH cycle early so that the people side of change synchronises the AH phases to the programme’s transition step.
- From the beginning reinforce that issues are decisions that are rising up the organisation and failure to make timely correct decision is what kills projects, programmes and benefits (and morale).
- Plan the programme backwards from today’s reality for the executive’s target, accepting only key enablers that match the business constraints into the baseline (or backlog). Whenever conduct at any step above shows disconnect replan as at step 1 and step 8.
- This is the “most programmes most of the time” basics but it isn’t everything.
The last insight is perhaps the most important.
 An issue is an off-plan situation where the person faced with action lacks either knowledge or authority to resolve the variance. When the off-plan rests with someone with knowledge and authority then we have a ‘problem’. Problems are what we pay staff to deal with day-to-day. Issues must be relocated to someone for whom they are just a problem. The threshold is determined by the authority delegated with the end-point.