Every sponsor with whom I have ever worked has wanted quick wins in the bag. This is not just impatience, although there is normally a good dose of that. A sponsor must have put their own credibility on the line in making the case for change, and needs to hold the leading coalition together, sometimes in the face of active opposition. Sometimes, such as in a de-merger I was recently involved in, there are significant contractual penalties associated with delay. Showing results through the delivery of value is an obvious way to win these battles. So, quick wins are a good idea. What a surprise!
One of the words often associated with transformation programmes is “complex”. What is really meant by this is that there are multiple strands of activity that must be brought together if the hoped-for benefits are to be delivered. It is common at the start to know that there is going to be lots of interaction during the delivery, without having a clear view of what its impact will be. This creates risks for the capture of benefit and the ability to deliver on time. Throwing additional resource at the matter is not a consistently reliable solution, quite apart from being an expensive one. One of the nasty reactions that I have seen in project managers under the cudgel in large programme delivery is that they tend to react by withdrawing in on themselves: they concentrate on delivering the products on their own list, interaction with other work-streams being the first discretionary activity to be cut when delivery deadlines loom. The result is reliably that the components of the solution do not fit together. The products are produced, but the benefits are not captured.
So how is a programme manager to address such a situation successfully?
There are some common approaches that are consistently seen where these situations are handled well:
- Plan and manage a stream of benefit delivery
- Use high-level architecture to get the big-picture right early on
- Simplify and iterate
One thing that is definitely not done is to shout “JFDI” and charge on. That way lies disaster where there is any interaction at all.
Managing a stream of benefit
Whilst what is normally heard is “give me quick benefits!” what is normally meant is “give me a good, valuable, consistent and reliable stream of benefit now, next month and next year!”.
The reason for this is that the battles must be faced up to continually. Not least for those who want to take your budget and apply it elsewhere. By concentrating on benefit rather than just products, and continually training your project managers to think the same way, you will make appropriate trade-offs when decisions need to be made. You will also negotiate effectively. If you take my person, these benefits will be delayed by x months. To negotiate this, you need a plan that tells you how much benefit you expect from what activity and when. Traditional product-based project plans are input-based, and do not tell you this. MSP is designed to be outcome-based and is written this way, so the thinking is all in place. It is just rarely done, as it requires a mind-set that is quite different from the way most project managers who have grown up through the ranks have been trained to think. Benefits realisation thinking has been around for years and is at last gaining some traction.
Some benefits, particularly those based on people, build up progressively over time. Some creativity is needed in thinking about what are the early signs of progress. Use these to set expectations of progressively improving maturity. I like to use maturity models for this. A recent client wanted to see progress in the effectiveness of handling incidents in an IT service. A first stage could be that most incidents are logged, then that the log is complete and accurate, and later that the log is being used to provide meaningful information to point out areas of improvement, and ultimately that repeat failures could be noted from the log and fed into pro-active resolution (Problem Management in ITIL terms). This gives some benefit early on. The rate of maturity can then be the subject of negotiation to ensure that it is fast enough in the circumstances. At all times the sponsor can see how far they have come, where they are, what is next. The failure to set such expectations can prove problematic as infeasible hopes can arise, leading to disappointment and worse.
Get the big picture right
The interactions between elements are initially unclear. Initial high-level planning of the major elements and how best to arrange and then build them helps to define the interactions that are absolutely necessary, plan when they should be delivered and thus to manage risk. Where there are off-the-shelf components of a solution that can be deployed, delivery can be greatly accelerated by using standard components with minimal customisation (some configuration being inevitable). The trick is to start with the right components for each area of the solution such that the overall set is optimised. This is a high-level thinking task, which is why the best architects tend to be highly experienced and bright.
The most significant risk at this stage is that one area of the solution is addressed in minute detail (e.g. Technical Architecture) and another is completely overlooked (e.g. Commercial management, people change). This risk is best handled by ensuring that the core team has an appropriately diverse set of experience. A good and balanced set of frameworks e.g. Enterprise Architecture, Transformation Management, Programme Management, Governance, can help too. I have investigated a number of services and programmes and been involved in more. In most that have hit trouble, basic items that are well captured in good practice frameworks have been omitted or given inadequate attention.
Simplify and iterate
It is no accident that all the major delivery methods seek to divide the overall programme of delivery into manageable chunks, get something working and deliver progressively to resolve interactions. This has the advantage of clarifying what is most important and supporting the progressive delivery of benefit. What is done should have a clear link to the organisation’s strategy and the desired outcomes of the programme. Clarity of thinking is required to achieve simplicity without cutting value. Rather than try to get everything planned out to the nth degree from the start, the wise start with a sensible first draft, using that to test and refine dependencies between work-streams. This is typically much simpler than attempting to work out all the links when it is not clear what is being tied together.
Caution is needed where there are fundamental design decisions to be made where the cost of rework will be high. The approach that is advocated in these is to establish principles early on, and test these carefully. If you cannot do this, you certainly cannot reliably build anything that depends on the principles.
Delivering major programmes will always be challenging. The achievement of significant value always is. There are some well-grounded approaches that can support delivery. The trick is to keep using them intelligently and to focus on what is most important; the delivery of value.