How to create a tranche plan
One of the key differences between projects and programmes is the need for tranche planning; organising the programme into a series of discrete, time-bounded, episodes as it journeys from the ‘as is’ to the ‘to be’ state. From that perspective a tranche is simply a time period containing a number of projects that moves a programme towards its vision. However this can be particularly troublesome for those organisations that think that a programme is, essentially, just a very big and very complicated project.
To really understand tranche planning and why it is necessary we should first understand a couple of fundamental differences between projects and programmes. It is too easy to assume that, because they are both about change, they are fundamentally similar – they really aren’t! To make the distinction easier, it can be helpful to look at them from a management perspective.
A project is predicated on delivering a specified product set within the parameters of a set of constraints. Even when we don’t know exactly what the product is (for example in a project using Agile approaches) we still need to be able to say what the minimum viable product (MVP) needs to be to achieve the outcomes. Without knowledge of this you can’t determine the limits of cost and time you’d be prepared to invest to achieve the outcomes that justify the investment. For such an approach to have a chance of success the situation must stay stable enough, for long enough, for us to achieve the outputs; otherwise the project is doomed to either breach its constraints and/or runs a really high risk of not achieving its benefits.
A programme, by contrast, is a response that explicitly recognises that the situation is not going to remain stable for long enough to achieve the end point in a single, pre-determined step. That is, there are multiple viable routes (some of which we don’t yet know or can’t conceive of) and the end point is likely to evolve or develop as we progress towards it. If we know and recognise that from the outset then it is clear that a project approach can’t work; we simply can’t know what the product set will need to be (even at an MVP level). So, if a project approach won’t work, because its meaningless to describe a product delivery within a set of constraints, what will? Step forward the programme. Rather than predicating the programme on a set of products within the limits of constraints it is a more flexible response designed to deliver increasing value in pursuit of a strategic vision.
This means the management focus must shift from efficiently building products within constraints to achieving value in pursuing a changeable goal. So, in a way that doesn’t apply to projects, we need to be able to plan and structure programmes to respond to different strategic imperatives and opportunities as they evolve or emerge. Tranche planning and management are the vital processes that allow this to happen.
In planning a project we are, from one viewpoint, determining the constraints saying “this is how long it will take and this is how much it will cost, to generate the output that you need”. The unstated assumption is that nothing, too significant, will change before you can deliver that output. Any change will lead to scope-creep and likely, a breach of the pre-determined constraints.
In planning a programme the approach must be to make progress towards a strategic goal whilst being unclear as to how you are going to get there. Part of such a response is to break the journey down into shorter-timescale episodes, called tranches, that allow you to make controlled and valuable progress towards intermediate positions.
Perhaps a couple of analogies might be helpful. If we assume that we are in Southern England and we need to be in Edinburgh for a business meeting this lends itself well to a project approach as we have a clear and unchanging objective. We can plan the journey by looking at the alternatives, train, car or plane and weighing up their cost, risk and utility to determine which we can afford and want and then we can execute that plan. Of course there are risks of delays and breakdowns but we can reasonably predict the worst of these and put in place contingency plans and actions that allow us to manage them. Good, standard project management.
Now, if we on the other hand are keenly interested in understanding Scotland’s culture, geography and scenery we would be facing a more complex situation with many different options for solutions and no clear, pre-determined, approaches or constraints guiding us on how to achieve it. For example we could simply research Scotland on the internet or we could visit it once, or a number of times – or we could combine these and other approaches. Such choices depend not on the solution and the constraints of the business case but how valuable understanding Scotland is to us as a long-term objective. In such a situation it doesn’t make sense to try and plan this as a project but more as a programme.
So if part of the programme were a visit to Scotland to see some of the scenery we might still be undecided on whether seeing the Electric Brae would be more valuable than taking in the Stone of Scone, Glen Coe or the North 500; we clearly wouldn’t want to plan the trip in the same way as the project to get to the Edinburgh meeting. We’d like some flexibility and some choice about how we achieve what value we want to from the trip. But we’ve still got to plan to make some progress so we could, reasonably, say that regardless of which destinations we did or didn’t visit to achieve the optimum experience, we will need to get ourselves to Scotland with the flexibility to determine our itinerary when we arrive there. So, the first tranche, of our programme might be to find a means, that gives us future flexibility, to get us to Scotland. Hence some time later we could find ourselves sitting in a camper van in the Southern Low Lands of Scotland reviewing the weather forecast before deciding which sites we’re going to take in and in which sequence. We have got to the end of the first tranche and achieved an island of benefit.
Islands of benefit are a state in which we have achieved a valuable, safe and stable ‘steady state’ position for the organisation. This state has made progress in moving us towards our vision and delivered some value although, theoretically at least, it would be possible to abandon the programme here without great loss or a significant legacy of risk or organisational turbulence. Islands of benefit are used to both demonstrate some attainment of benefit and to plan the next tranche of the programme.
So here we are in the Lowlands of Scotland facing a choice as to whether we take in the Electric Bray and Ayre races (covering some significant scenery and a cultural highlight of the area) or whether we take a dash North up Glen Coe and onto the North 500 via Ullapool and the rugged North Coast. Either are equally valuable to us but the time we have to make our journey means they’re mutually exclusive. It’s at this point that we might realise there is a settled period of weather (a rare treat in the North of Scotland) and so opt for the North 500. So tranche two is looking like the Northern road trip but, as we get beyond Glen Coe and stop at Fort William, a local marketing campaign draws to our attention a celebration of Islay Whisky, occurring in the Isles over the next few days, that we are about to drive past and of which we were previously unaware. Happily the distillation of Whisky and the Western Isles feature high in our list of valuable experiences to achieve our objective of absorbing both Scottish culture and scenery and so we can flex the journey to achieve more value during the second tranche. We will drop the notion of the North 500 in favour of a quick ferry hop to Islay. You see? This is all about maximising value in uncertain situations that present multiple options; not about determining a constrained ‘dash for the line’ against a clear and ‘static’ objective!
This value predicated (rather than output and constraint predicated) approach to planning in a series of tranches is central to programme management and non-existent in project management. It does mean, of course, that tranche planning is central to both management of the constituent projects in each tranche and to the demonstration, to the governance structure, of the achievement of strategic corporate value.
So how do we set about tranche planning? Well if you’d like to know about that, please get in touch!
Nick Dobson, Principle Consultant
Nick is a highly experienced consultant in project and programme management and the sponsorship of such initiatives. A practitioner, with over 25 years of experience, he has been deeply involved in projects, throughout the lifecycle, as well as discharging operational management functions in a variety of sectors. Nick can be contacted via email at NDobson@citi.co.uk