Given Managing Successful Programmes (MSP) is for programme management what PRINCE2 is for project management, you’d expect to find a rather rigid process at the heart. So I was surprised to find, when re-reading the 2011 edition recently, active encouragement for agility. Admittedly this is agility in the wider sense rather than specific practices from the Lean-Agile movement but any agility looks good to me.
This post is not about how to make MSP more Agile – although I’ll make a few suggestions – but is merely a commentary on how Agile MSP is coming out of the box.
The MSP Agility Scorecard
MSP Agility Scorecard
The good news is that MSP scores well on “Responding to change over following a plan” and “Customer collaboration over contract negotiation”. In fact MSP is very agile when it comes to embracing change.
Despite the fact that some aspects of MSP are inherently agile there are other aspects which are more, well, rigid. In my assessment MSP didn’t score so well against “Individuals and interactions over processes and tools” and “Working software over comprehensive documentation”.
I think the level of agility within MSP can definitely be taken further. MSP practitioners would do well to adhere to the two Agile principles of simplicity and face-to-face conversations, rely less on process, go light on documentation, and allow their projects some agility as well. All of which would help with being an agile programme manager.
The remainder of the post adds a bit more detail in the comparison of MSP against each of the Agile values.
Responding to change over following a plan
There seven underlying Principles of MSP (p. 17):
- Remaining aligned with corporate strategy
- Leading change
- Envisioning and communicating a better future
- Focusing on the benefits and threats to the them
- Adding value
- Designing and delivering a coherent capability
- Learning from experience
Two of the MSP principles,”Remaining aligned with corporate strategy” and “Learning from experience”, are about responding to change. The effect of these MSP two principles means a programme has a flexible scope, uses just-in-time planning and is a learning organisation.
Transformational programmes are usually quite long and complex with considerable uncertainty. To remain aligned with corporate strategy such programmes must have a flexible scope. In fact MSP assumes scope changes are inevitable and frequent. MSP does add the proviso that these changes must be applied in a controlled and managed way. This should resonate with Agilists who are supposed to “Embrace Change”. In fact the Agile methods have mechanisms do deal with change in a controlled and managed way if that is appropriate to the context.
Change can also be as a result of the programme team learning from experience. The MSP view is that “a programme is a learning organization in that it reflects upon and improves its performance during its life” (MSP, 2011, p. 22). Self-reflection by the team is also one of the Principles behind the Agile Manifesto.
Because of the level of change expected in a programme MSP advocates planning a tranche just before it starts. This is the classic application of agile just-in-time planning.
Worth mentioning that MSP does not allow a project to have a flexible scope or plan. More on that later.
I gave MSP a tick for “Responding to change over following a plan”.
Customer collaboration over contract negotiation
Within MSP “leading change means actively engaging stakeholders” (MSP, 2011, p. 18) and building trust. This seems to related to two of the Agile values: “Customer collaboration over contract negotiation” and “Individuals and interactions over processes and tools” (Agile Manifesto).
MSP is quite explicit that stakeholders have to be managed as individuals to get the hoped for outcomes from a programme.
Managers sometimes forget the obvious: stakeholders are individuals or groups with feelings, perceptions, desires and influence.
…
Programmes managers need to think of stakeholder engagement not just as a system of tasks and managing things, but also as a way of achieving influence and positive outcomes through effective management of relationships. (p. 60)
So I also gave MSP a tick for “Customer collaboration over contract negotiation”.
Individuals and interactions over processes and tools
I’m not sure MSP would really advocate valuing “Individuals and interactions over processes and tools” (Agile Manifesto).
Having said that, people and their relationships are central to the MSP approach. If you drill down into the MSP principle “Leading change” and the MSP governance theme “Leadership and stakeholder engagement” you’ll find people and their interactions. Programme management within MSP is meant to be “actively people-oriented” (MSP, 2011, p. 18). Programme “leaders engender trust through leading with consistency and transparency“. “Well-led change focusses on people, using their strengths and abilities and bringing together these people and their skills into play at the right time” (MSP, 2011, p. 19). “Good leaders take seriously the attitudes and agendas of individuals” (MSP, 2011, p. 60).
On the downside MSP isn’t quite so people oriented in the subordinate projects. MSP says, in the context of engaging stakeholders, that:
Programme management needs to be much more actively people-oriented than might be the case in a project. (p. 18)
Unfortunately although people are important in MSP so are processes and tools. MSP is, after all, a process framework. And, to make it worse, the MSP process is complicated. Admittedly the MSP transformational flow only has six processes and looks a bit similar to the Scrum process. But throughout the transformation flow you’ve got to factor in the seven principles and the nine governance themes. That makes for a complicated beast … which explains why the MSP book is 301 pages long. That level of complication doesn’t really align with the Principle behind the Agile Manifesto about simplicity.
And although MSP emphasises the importance of treating stakeholders as individuals, it means the stakeholders outside the programme team. MSP has little to say about managing the team members, which is central to the Agile approach.
And the final “although” for this section, although MSP makes a big deal about communication, a lot of this communication is via documents. So not much support for another Principle behind the Agile Manifesto about face-to-face communication.
So, on balance, I gave MSP a cross for “Individuals and interactions over processes and tools”.
But speaking of documents …
Working software over comprehensive documentation
I had to do a bit of a translation with this value to make it fit within the context of a programme. In a programme context this Agile value would be “Delivered capability and benefits over comprehensive documentation”. In MSP? Not so much.
I think MSP Practitioners would be okay with the Principle behind the Agile Manifesto about value:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Of course in a programme context you have to replace “delivery of valuable software” to “delivery of value”. As evidence for this consider:
- “Programmes are primarily driven by the need to deliver benefits” (MSP, 2011, p. 75) whether economic, effectiveness or efficiency.
- “A programme only remains valid if it adds value to the sum of its constituent projects and major activities” (MSP, 2011, p. 21).
On the downside MSP specifies a lot of documents. 28 types in fact. All compulsory for a programme. There are so many documents that MSP has a special programme role, the “Programme Office” to manage them.
Sigh. I gave MSP a cross for “Working software over comprehensive documentation”.
References
Best Management Practice. (2011). Managing Successful Programmes (MSP) [4th Ed.]. London: TSO.