If you've watched the previous two lectures, I hope you have because you need to, to make good sense of this one. If you've watched the previous two lectures, you've seen how we build up the story of the project lifecycle, why we have stages in it, and what those stages mean. I promised in the previous lecture that I explain why the state boundary at the end of the delivery stage helps us to understand one of the main reasons why projects either fail, or more commonly simply go over budget or over schedule. And if you remember, this last stage boundary before the closing stage, is where we hand over the last of the project. deliverables, and we test whether the project deliverables are fit for purpose. But here's the problem.

All too often, when it comes to the detail, the planning stage, project manager goes to their boss to their client to their sponsor, and says, Hey, boss, what do you want? Because we need to put down a specification of the design for what we're going to produce, whether it's an asset, whether it's a product or service or a new process. Then what happens is the client or the boss says, Well, you know, I'm sure you understand what we need. I'm very, very busy. I haven't got time to define it for you. You move on mister project manager, you go on to find the project, you sorted out because you're the expert.

And then what happens? Well, the project manager is flattered and they call with their clients or their bosses desire to leave the project to them. So they go and do a good job. They write down a specification for what the project is going to produce. And they design the outcomes themselves based on their expertise, their knowledge, and the knowledge and expertise of a team that that symbol, which all makes very good sense. And once they've got that design, they go ahead and deliver it in the delivery stage.

When it comes to hand over there, though, that's where the problems arise. Because when it comes to handover, the boss, the client, turns up. The project manager turns the boss and the client says, Here it is, this is what we built for you. And the boss or the client takes a look at it, and they say, Hmm, that's good. It's good. I can see you've done a very good job.

There. The only thing is it's not quite what I wanted. And at that stage, the very best that the project manager can hope for is a negotiated settlement for more time and more resources to make it right for the client. Worst case scenario, get into arou. You get into litigation, and all because you didn't do the work. It's no coincidence, therefore, that I have shown in my life cycle model diagrams that you've seen.

The definition and planning stages occupy approximately half of the duration of the graph. It's not a rule. It absolutely is not a rule that half of your project should be taken up by defining and designing your project. But it's not a bad rule of thumb. It's not a bad guy. Because one of the biggest mistakes The new inexperienced project managers do is they rush their way through defining the project, they rush their way through planning and designing and specifying the project because they want to get on with what they think of as the key task of delivery.

But if you rush your way through definition, and planning and design, then you don't really know what you're delivering. And so you're forever chasing your tail and making it up as you go along. Invest in the design stage, and make sure you fully, fully engage your client, your boss, and all of your stakeholders. If you don't do that, and handover becomes difficult, but if you do do that, then the delivery state, it's a piece of cake. You've got your design, you've got your plan. delivery is just about executing that plan and handover Conceptually, handover should be you and your boss or your client standing, looking at whatever it is you've delivered.

You've got a checklist with all of the specification laid out. They've got a matching checklist with their specification laid out, and you can go through that checklist. Got that tick, got that tick, got that tick, tick, tick, tick, tick, tick, project delivered, hand over achieved signature on the bottom, the specification ready to close down the project. Now that's pretty practical. That's excellent project management.