Control is simply not enough: thoughts you ought to consider for programme management
Managing programmes is never easy as management control varies from one to another. But before I share my thoughts on how to manage this effectively, let’s take a look at the different characteristics of projects and programmes.
Project managers are often considered control freaks; I have seen examples of that. Those I have worked with in my career have demonstrated this to varying degrees (some more extreme than others!). As a project manager I can admit that I like to have the advantage of seeing the complete picture and the ability to influence and/or direct activities for the best outcome of the project.
We know that projects and programmes differ. Projects provide the specific outputs that contribute towards the outcomes and benefits that a programme is set up to deliver. Such varying characteristics necessitate different management techniques. However, both a project and programme manager need the ability to integrate stakeholders across multi-functional organisational structures and hierarchies internally and externally. Programme managers must also integrate multiple projects.
Programme management is different to project management. Control is reduced. I am not sure if there is an exact science here, but it feels like a ratio must exist and you will have experienced this too. As programmes grow more complex with multiple project outputs required, more parties involved, more agendas, greater dependencies on others to deliver and especially where significant dependencies on external stakeholders exist, the ability to directly control outcomes reduces. The importance of influence then increases, and it gets more difficult to control the successful outcome of meeting the objectives.
This is logical so nothing new here, but fully recognising and appreciating this, and ensuring a structure is in place across all key stakeholders to deliver alignment with clear communication is vital.
The role of the programme manager is to knit this together by ensuring that each of the projects within the programme achieve the outputs required to deliver the associated outcomes and benefits. The really tough part of this is that the programme manager is likely to be managing a mix of:
- control - projects within their organisation and under their direct control.
- control and influence - projects within their organisation that contribute but are not under the programme manager’s direct control.
- influence - projects outside of the organisation that contribute to the outcomes of the programme and are not under the programme manager’s direct control.
Often project and programme management literature is written with assumptions that a programme comprises stakeholders aligned at all times with a common agenda throughout. We know the reality to be different, especially on multi-year programmes with changes of: government, key personnel, assumptions from the bid stage and business objectives. All of that would have a significant influence on delivery. So how does a programme manager achieve the goals of the programme?
It isn’t easy…
Here are some thoughts for you to consider on your programmes.
- Programme route map. Be clear on the programme objectives. Map out how they are achieved. What benefits are to be realised? What outcomes do these benefits need from the programme? What outputs do these outcomes need from the individual projects?
Acid test: do you have a clear map from end to end of the structure of how each project output contributes to a programme benefit, which contributes to the programme objective?
- Clarity of contribution. Once you have your route map of outputs per project be clear who is accountable for delivering each. Using the categories above, which projects are delivered under the control of the programme manager? Which are partially under their control and influence, and which are entirely via their influence? Create a stakeholder management plan based on the known stakeholders, their influence, their interest and their current position (ie in/not in favour).
Acid test: are all parties signed up to deliver their part of programme? Are interfaces clear? What does each project require from one another? Is the scope baselined and does each party recognise what this is/agree? Does the programme manager have a stakeholder management plan and strategy?
- Management structure. A structure is required to manage the above over time. Many factors will influence possible changes to the programme. Change is not a bad thing, but it needs to be understood and controlled. Define who needs to meet, when and for what purpose. How will multi-party project performance be reported/managed? Who is accountable for the multi-party schedule and achieving the objectives? How are changes managed and agreed across all parties? How are interfaces of different types managed (technical/commercial/operational)? What if certain parties don’t meet the expected performance levels and how is this managed?
Acid test: Does a series of meetings, likely at various levels of hierarchy and technical focus, exist? Is it giving you the optimum opportunity to deliver the programme objectives? Is there an agreed Terms of Reference for the programme (a programme charter perhaps) that each party has signed up to underlining their commitment? (Often a single commercial contract will not exist across all parties in the programme.)
As mentioned above, achieving the goals of the programme is not easy. It will vary depending on the specifics of your programme, whether it is small, large, international, politically contentious, technically innovative, or socially conscientious, etc. I hope that my thoughts can make it easier to manage programmes and achieve goals. I welcome your views on this, and pointers to any models that exist to help with managing the scale and complexity vs control and influence balance.