We were talking in the last video about the four stages of a standard project lifecycle. But the question that often arises at seminars and training that I conduct is this. Why do we bother splitting our project into stages at all? And the answer is that there are a number of very good reasons. But one that in my mind dominates has been more important than all the others. But let's start off by looking at the basic reasons.

And the most fundamental, I guess, is the projects or big, scary things. We're trying to achieve quite a lot. And human beings well. We're fundamentally descended from the central Sort of creatures of hedgehogs and of course, what does a hedgehog do? When it encounters something big and scary, looming down upon it? It curls up into a small ball.

And it hopes that the truck thunders on past without doing any damage. As human beings, that's our instinct as well forget fight or flight fright is our number one response to something big and scary like a project. So what are the stages do the stages slice the project up into small chunks. And of course, once we've got a small chunk, thin, it's far less scary so we can get on with it. And the first stage is the definition stage. It's a small piece of work.

So we can define our project. And once we've defined our project, and we understand what we're doing, we can get on and plan it. So the first reason is to give us a sense of momentum and make it easier to deliver what we need to deliver. The second reason is to look at the nature of the chart and you'll see, the area under the curve that represents the lifecycle actually represents the amount of resource it takes to deliver the project in that stage. And that's because the curve, the line of the curve represents a crude approximation to the amount of work or the amount of effort that needs to go into the project at each time. And therefore the area under the curve is the cumulative amount of effort, whether it's resources or time spent by staff, whether it's budget.

So consequently, the stages give us an indication, firstly at the scale of resource that is needed to be deployed in each stage. But secondly, and perhaps more usefully, each state has a different character. And the character of the stage means that you're going to need different resources different types of materials, different assets, different equipment, and crucially different people with different skills to get involved at each stage. So our lifecycle model helps us to create a resource plan. It also, of course, creates major points along the way the project, what are we going to call later on? milestones.

But here, for me, is the most important reason. You see, if we slice off project up, that helps us get started and it creates momentum. But the thing about momentum is that it keeps on going. And I'm sure many of you watching this video have had experience of observing or even being involved in projects that got started with quite a lot of fanfare. They were a great project, and everybody knew this project was needed and going to deliver something valuable Things change. The environment changes the commercial environment, the trading environment, the technological opportunities change, the regulatory and legislative environment changes.

And all of these changes can mean that as you work your way through the definition, even the planning stage of a project, you start to learn things, you start to conclude that maybe the project isn't quite a good idea after all, but the project's got momentum. So the project team keep on working on it. More and more people in the organization are looking at this project and they're saying, why are we doing that? What's the point? It's kind of like the Emperor without clothes. But the team marches on.

That project manager leads the project forward to delivery and eventually the project delivers magnificently. Something that is no longer needed. which then gets shoved away in a cupboard somewhere or put on a shelf and forgotten It's waste. And it's a breach of corporate governance. For me the most valuable part of the stages, it's not the stages themselves. It's the boundaries between the stages.

And these boundaries change the presumption from we've started our project. So we're going to finish it, too. We've started our project. So we're going to get to the boundary and review it. And know these boundaries. We ask two questions.

And the first question is a backwards looking question. We look back at the work we've done, and we say, Have we done everything we need to consider this stage to be complete? At the definition stage, we're saying have we clearly defined what the project is on what the project is not? And if the answer is yes, then we can ask the second forward looking question. Having learned what we've learned, and observing what has changed while we've been here. learning it, is it still the right thing to do to move forward with the project?

And if it is, then we can go on and plan the project and define the project and build a business case. So the test our first boundary, is does this project make good business sense? Does it look like this project is aligned with our organizational values? Our vision, our mission, our objectives, our strategy? And does it look like it will deliver good value for money? Once we've planned our project in detail, and we've designed it, we can build a business case.

And the boundary at the end of the planning stage is where we ask the question, should we invest? Because the area under the curve, the delivery stage is a big area, a lot of resources. And if the answer is yes, we should invest when we go ahead and we deliver the project and many forms managers will divide their delivery stage up into chunks itself. Maybe there'll be a prototype stage or a pilot stage, maybe there'll be a series of rollouts. Maybe there'll be some testing stages at the end. Conceptually, the end of the delivery stage is marked by handover of the final element of the project's deliverables.

And the test here is very simple. Are the deliverables that have been handed over fit for purpose? If they are, we can go ahead and close the project down. But I'll say now, but there's going to be a short video following this one. Which shows you why that are they fit for purpose question helps us to understand one of the Communist reasons why projects either fail or more often simply go over budget or over time. So if you're interested in Why that question can link directly to problems with your project, then don't forget to watch the next video.

In our final stage in the closed stage, we have three things to do to close our project down in orderly fashion. If we do, we're going to ask a very simple question we're going to ask our clients or our boss or our project sponsor or our director, can I consider this project to be closed? And if she or he says yes, and signs that off, your project is over. For simple stages,