I’m a programme manager, an Agile Programme Manager. Some people don’t know what programme management is or what programme managers do. So, for those who are wondering, I thought I’d described what I do.
List of Programme Manager Responsibilities
There are lots of lists about what a programme manager does. Three I looked at were by Elizabeth Harrin, Expert Program Management, and Neil A Walker. These lists are very similar and correct as far as they go.
I want to give a slightly different take on what a programme manager does. Take a step back and look at the role from a slightly higher level and, of course, with my spin on it. I think this is what I do:
- Find the purpose
- Manage the money
- Shape the programme
- Guide the team
- Get people talking
- Grease the wheels
- Make it real
- Iterate until done
These are not steps in a process. They all, more or less, happen simultaneously. Having said that, there is a lot of finding the purpose at the beginning and iterating starts later on.
Find the purpose
I blogged recently about Purpose Finding. Finding out why we’re doing something so that we don’t do anything unnecessary. My main tools for purpose finding on a programme are the Programme Vision and the Benefits Map.
I spend a bit of time at the start of my programmes identifying the vision. This is a “postcard from the future” describing a better future to attract buy-in, encourage motivation and ensure activity-alignment.
I also draw up a benefits map. These maps are essential tools for programme managers as they answer two key questions:
- Why are we doing the programme?
- How will we realise the benefits?
The vision and the benefits map provide a high level Programme Scope. They help draw a line between activity that is of interest to the programme and that activity that isn’t. The main benefit of Purpose Finding is so you only solving problems you need to.
Manage the money
Money is power and a programme manager without money has no power and very few options. So I spend a lot of effort managing the money. I help do the business case for the programme to ensure I get sufficient money to deliver what I need to. I track programme spend against the budget on a monthly basis. I adjust the forecast as new information comes to hand to make sure I’ve got enough left to deliver against the benefits and vision. I petition for more funding if that becomes necessary.
Don’t get me wrong. Despite the fact I do the programme accounts, I’m no accountant. I do it because I can’t fulfil my delivery responsibility without knowing that I’ve got enough money.
Shape the programme
I need other people to do what I do. Usually a lot of people. So I have to decide on the Programme Organisation I need. I divide my programme into workstreams that, more or less, correspond to Agile Teams. Most of these are technical but at least one is the Business Change workstream. Each of these teams need a goal that fits with the wider programme objectives. The Benefits Map can help identify the projects, their goals and also suggests the timing of when you need that workstream.
Having decide on an organisation I have to find the people. Usually some people are already be on hand and will be assigned to me, so I just have to figure out where they are best deployed. However, typically most of my team will be external and I’ll have to recruit. I personally focus on filling the senior positions i.e. the Technical Architect and project managers. Other folk are better placed to fill other roles, e.g. developer and tester. And, of course, some teams might be outsourced so recruitment might be for a vendor.
The other part of “shaping” is Programme Governance. Daily, weekly, fortnightly and monthly meetings – the sort of thing I described in my Example of Day to Day Governance on an Agile Programme.
Guide the team
If I used one sentence to describe what I do I’d say “I keep people focussed”. I keep the people in the workstreams focussed on their specific goals. I remind everybody, both team members and stakeholders of reason we’re doing the programme – the strategic objective from the Benefits Map.
I’ve drawn the parallel between a programme/project manager and a shepherd or sheep dog before. I do a lot of rushing about to find out what is going on and give me a chance to intervene in a timely fashion. All part of management on the ground. A lot of that is attending governance meetings of one type or another. All these meetings are to ensure the workstreams are aligned with the programme goals, and with each other, and the programme is aligned with overall business strategy of the organisation. And of course there is a fair bit of Monitoring and Control to ensure the sub-projects are on track.
I put a massive focus on Risk Management. I go where the risk is to ensure I Don’t Get Smacked in the Face. I focus on Programme Risks rather than Project Risks and ensure the project managers look to their own RAID. If I can’t resolve or mitigate something then I escalate by flagging the risk/issue as RED.
Change Management is also very important to me. Often I have to say “no” because a suggestion is not related to the Programme Purpose but it can also mean saying “yes” because the proposal is essential to achieve the Programme Vision. Either way, change management means the decisions are made consciously.
Unlike other programme managers I’m not super interested in milestones. I am very interested in steady progress demonstrated by working software and shown by productivity measures such as throughput or velocity on a cumulative flow chart. These are unambiguous because they acknowledge that 90% Complete not = Done.
Get people talking
The Agile Manifesto has a bit to say about talking. One of the values is:
Individuals and interactions over processes and tools
And one of the Principles behind the Agile Manifesto is:
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
So not surprisingly I spend a lot of effort getting people talking. There is a formal aspect to this that is part of Programme Governance leading to daily, weekly, fortnightly and monthly meetings. As you’ll know from my Example of Day to Day Governance on an Agile Programme there are daily standups, weekly team meetings, fortnightly show n tells, and various steering groups (either fortnightly or monthly). Lots of talking.
The informal aspect are the impromptu meetings, cross desk chats, corridor conversations, camping at people’s desks when an issue comes up, encouraging one person to talk to another (sometimes when they sit next to each other), coffee catch ups, and lunch with the gang. Then there is the advantage of sitting in a open space with (at least one of) my teams – observing, eavesdropping and overhearing so that I, and others, can intervene when something comes up.
When I do have to resort to written communications I like to keep them simple. For example my Agile Status Report for Executives: Best, Worst, Throughput is just a couple of paragraphs. I also like visual signals and use a RAG status where Red is a call for help. Both of these are to trigger a conversation.
Although I obsess about risks and issues I try to Report Success Stories Alongside Formal Benefits. These success stories always seem to get folk animated – and talking.
Grease the wheels
I, like all programme/project people, face a dilemma. I am paid to be responsible for things I cannot control. Faced with a difficult situation I don’t fall into the fallacy of control, instead I agitate.
A group of people I often seek help from are resource managers. These are the people who manage the people that I need for my programme. I spend a lot of time talking to the resource managers teeing things up so that I’ll get the people I need, when I need them.
A variation on that is when I need work done by a development team that I don’t directly control. In this case I have to agitate around priorities to ensure the other team does the work in a timeframe that fits with my programme.
But the most important group are the influential stakeholders, specifically the members of the Steering Group. My post on when I suffered a 3 Million Pound Budget Cut demonstrates how this group can help. I couldn’t solve the problem so I went looking for help from the programme sponsor and programme steering group in general.
Make it real
The short summary of what I do is Build capability, Roll it out, and Deliver Business Benefit. The latter two of those – roll capability out and deliver business benefit – are about making the programme real.
Many programmes are executed in a waterfall fashion. I have a more grounded approach. I don’t want to talk about what we’re going to do; I want to do it.
I believe in relentless progress. So I constantly push my teams to get to Done. Whether features or projects the aim is to get them 100% finished. Getting features live early means they start delivering benefits early, long before the project or workstream delivering them is complete. Similarly, finishing a project / workstream early means the programme is delivering the associated benefits early.
Iterate until done
Nothing is set is stone, particularly not for an Agile Programme Manager. So I have an Iterative Incremental approach to programme planning and execution.
Although the Programme Vision is usually stable over the life time of a programme it is worth revisiting it to see if the vision is still relevant to the organisation. However I continually revisit the Benefits Map
As long as there is money left in the pot I have the ability to deliver more capability, more value. However, I don’t particularly feel tied to the original budget. The total amount, yes, but not the individual budget lines. To ensure I deliver against the strategic objective and final benefits I need to be able to flex where the money is spent.
I Reinforce Success. I back the initiatives that are working, with longer time, more scope, more money and/or more people. I also stop those that are not fulfilling their promise. The projects are not important; the outcomes are.
Reinforcing success is part of a more general process of grooming the project portfolio within the programme. Ensuring I’ve got the right projects and that they are delivering. I look for gaps in the program and fill them in where possible. Sometimes the gap might be a role / person. Sometimes it is a workstream / project.
The most important thing is the learn and improve. I encourage my teams to Innovate Constantly with conscious experimentation and constant fine tuning.
Of course eventually the programme is “Done” and it is time for closure.
References
Expert Program Management. (2009, May). What Does a Program Manager Do?. Author.
Harrin, E. (2011, 21 Feb). What does a Programme Manager do?. Project Manager Tips.
Walker, N. A. (2010, 21 January). What does a programme manager do all day?. PPM Practitioner.