So, if you look at the MSP, particularly the program process model, you'll see in there that it goes in a loop. So, you start off with figuring out what you're gonna do this time, then you do it, then you check whether it works, and that then reinforces your decisions on the next loop. That loop is what's called a tranche. So a tranche is a section of the, the program, that results in you delivering an outcome. So, we're gonna do all these projects and then boom, this-, the world's gonna be different, and then we're gonna do all these projects and boom, the world's going to be different.

So, rather than thinking of a tranche the way you might-, in a project, you think about stages and you think of them as being like a discrete box of work where you do a certain amount of work and something comes out. A tranche is more about that end-point, so it doesn't really matter when it starts, so tranches can overlap, for example. It doesn't really matter when it starts, what matters is where it ends. So, a tranche represents from the point you start doing work related to this outcome to the point where you achieve that outcome, and the idea being that once that tranche is delivered, you should then start seeing the benefits come out of it.

That point where the tranche delivers is what's called the landing point, so the landing point is the point in the program where you should have achieved something. And when I say achieved something it's important to recognize that the program should be delivered from the point of view of the business, so achieved something means achieved something in the eyes of the business which is an outcome.

So, what I'm saying is it doesn't-, you might have delivered a project but as far as the business is concerned if that project's not giving them anything it might as well not exist. It's only when all the projects have come together, produced their capabilities, and you've then got an outcome of some sort, a delivery of, like, tangible change that's going on that the business can see, can you then stop and go, 'So what do we reckon guys, is this worth it, is it working?'

So, that's what a landing point is, a landing point represents the end of a tranche where we stop and we go, 'Where are we, what's happened, how are we going?' Those tranches should represent what's called step changes in capability, so it's almost like you're pushing the business through the gears. So they might-, you know, you start off with an empty space and now suddenly we've got a small amount of work we can do and then we build on that and deliver more services, build on that and deliver more services so you're pushing the business through the gears.

But, the point is at each of those landing points there should be something that's worth having. There's something you can show people and say, 'Look, we've delivered,' because again that builds momentum, that gets engagement from the stakeholders and it shows that the program is progressing and going somewhere. So, of course, the way we're delivering the change, the way we're delivering program management is using MSP. So, we've already got a recognized framework sitting on top of all the change that's going on. Delivering outcomes, delivering benefits, getting the program through to, to the end, but it's important to recognize that the outputs and therefore the capabilities are being delivered by projects.

Now, those projects can deliver things in a whole number of ways and that what's known as multi-modal delivery. So, different projects might use different ways of working, they primarily, though, fall into two main camps. There's what's called Agile or linear or walk forward as it's also known, and, you know, without going into too much detail about it because it's not really what this is about, but essentially a linear approach is what's known as, sort of, classic or traditional project manager where you have distinct large scale stages of development. So, you might build the foundations of the house and that's one stage, then you build the walls of the house and that's another stage, and on again. And one of the key points to note about that is that commonly with a linear approach you don't really have a working product until the end.

But, when you're doing things where changing your mind is incredibly expensive it fits. An Agile approach is where, it's not mean to say that it's making it up as you go along. Because it is, it's making it up as you go along in a positive way, because what you're doing is you're learning very quickly and looping round in two, two weeks is normally the standard approach that you use, often referred to as a sprint or a time box, sometimes it's referred to or just an iteration.

What that means is that from a program point of view if you've got a linear project-, say as a program manager you're looking down on this project, you know that there's going to be these key moments in the project that could be at different times. One could be a month away, one could be six weeks away, another one could be four months away, where specific things are gonna come out and so the program can plan itself around these major developments from the project.

Whereas if it's an Agile project it's releasing usable content every couple of weeks. Now, if you think from a program point of view, from a business change point of view, if you're changing the business every two weeks, that can be quite stressful. You know, you're changing processes, you're changing approaches, so a common approach that people use with Agile when you're working from a program point of view is to bunch up some of those sprints, some of those releases into one, sort of, major release. So, you let it maybe have three or four sprints going together, then the BCM picks up all of those outputs and capabilities and then introduces them into the business in one hit.

So, you have-, sometimes they're called release windows or delivery windows or something like that. But basically, it's the same idea. We're delivering by a tranche, we're letting the projects produce their outputs. We're then collecting them up as capabilities, handing them over to the business change manager who takes them into the business and delivers them as change. So, in a lot of ways, you could argue it doesn't really matter how the projects are delivering, as long as we understand how they're delivering and work with it in order to deliver outputs.

The absolute key golden rule though is that whatever method you're using, it's gotta work for the business. It's also possible that you could have a hybrid approach, so you might have like a linear project overall but within certain stages, you're delivering it using Agile. So, you know, you've got three months of work you're doing but you're delivering that in two week sprints and then that culminates in something you're producing there. Again though it doesn't really matter from a program point of view, as long you appreciate the way they're doing things and deal with their outputs appropriately in order to lead them into a recognizable change for the business.

Views from the expert on the structure theme

About