Before we look at what a project lifecycle is, let us be clear on what the term means generally, in ordinary language. A lifecycle means a series of types of event that follow each other in the same order; this series can be expected to repeat, perhaps with some variation, for other things of the same kind. So the human lifecycle begins with birth, proceeds through childhood, adolescence, adulthood (which begins often with naive enthusiasm and concludes with tempered resignation), into senility and then ends with death. Shakespeare describes the human lifecycle more poetically in the seven ages of man. Different individual people may have different lives some mature early, others exhibit teenage tendencies in their mid-twenties, some become senile at 60, others are as sharp as a pin into their late 90s or beyond. Death can end the cycle early, but the point is that there is a pattern, and it is so useful to know where an individual is in their lifecycle when dealing with them that we do this unconsciously: we don't treat the two-year-old who rushes into our bedroom in the middle of the night in the same way that we treat the adult who does the same thing.
So it is with projects. Projects, whatever their differences, all share roughly a common lifecycle by virtue of being projects, and as a project manager or sponsor you need to know what the general project lifecycle is and how the focus of your job in the project changes at different stages in the lifecycle.
The simplest lifecycle is:
beginning middle end
Note that already this simplest of project lifecycle models identifies one of the distinguishing features of projects. Remember that everything in an organization is either a process or a project. Projects differ because they have definite start and end points, whereas processes run continuously. Has the project started yet? Has it finished yet? These turn out to be key questions in many project governance situations. Large business corporations and government organizations often have a large number of projects that are like Frankenstein, neither truly alive nor dead. This is perfectly reasonable if the projects have deliberately been put into a state of suspended animation, that is put on hold, while waiting for some other factor to be resolved. What happens too often, however, is that the projects should have been killed off and the resources reallocated to more promising projects, but poor project governance, or poor management, allows a number of essentially pointless activities to continue under the guise of projects.
Table 2.5 lists some examples of where project management should focus at different stages of the project lifecycle. Note that where a project is broken down into several different stages, each stage can follow this phasing. So, taking one of the points illustrated in Table 2.5, if we are in the middle of stage 1 of the project, we certainly should already have had a plan for stage 1 worked out, but we should not be at all concerned if we have no plan yet for stage 5. This point introduces the relationship between project structure and project lifecycle, both of which are also related to how to manage the project team and to organizational structure. The experienced sponsor and project manager will be aware of these relationships and their practical implications for the project that they are managing at the time.
Project phasing and the project lifecycle
The project's lifecycle is made of phases. This is a straightforward idea, but it is valuable to understand it clearly, as by doing so many problems in project management can be spotted earlier and managed better. A key implication that follows from the idea of the lifecycle is that there is a sequence in which to do phases in a project. It may be that there are two or more equally good sequences, but what matters for project management is that the sponsor and the project manager pick a sequence and either stick with it or agree to change to a different sequence.
What should that sequence be? There is no standard model that applies across all projects. The choice of phases and how to sequence them varies according to the industry in which the project is, and also according to the way in which a particular performing organization works. Some things in project management are completely general and apply across all projects, for example the kinds of questions that should be answered in a project charter (or project initiation document), but phasing is not like that.
The question of how to divide up the project into phases and what sequence they should be in will fall into one of two circumstances:
If there is an established model lifecycle for your project, then obtain it (or them) and review it to ensure that you understand how it applies to or differs from your project's needs. It may be useful to adapt such models to some extent to your needs, but most often it is a case of adaptation rather than starting from scratch. In any large organization that runs projects, there will usually be several such models, each with their own group of supporters. How easy it is to find such models depends on the intellectual capital management system or knowledge management system in your organization. If you meet the supporters of a particular model or template for a lifecycle, they will usually be enthusiastic about their particular lifecycle model, but you should try to understand the implicit assumptions underlying their support for their particular model, especially what kind of project it is designed for and what kind of problem it was designed to solve. Selecting a lifecycle model is like selecting any tool. The tool can be excellent without being an appropriate tool for your particular job. And there is also the danger of making the best the enemy of the good, by wasting time on trying to select the perfect tool, wasting time on minor differences between very similar lifecycle models, when any good enough tool would do and the time saved should be spent on some other project activity. Also consider the needs of your organization rather than just your project the organization stands to gain from standardizations of tools, including lifecycle models, and you must be prepared to use a lifecycle that is slightly less than perfect for your particular project because of the broader strategic gains to the organization from using a standard set of lifecycle models. The boxed text describes some standard lifecycle models and Figure 2.6 sets out some examples.
Figure 2.6. Some examples of various project lifecycles
Three different real-life examples of project lifecycles are shown above, together with the main activity and typical milestone deliverables for each phase. Note that all of these lifecycles are essentially variants on the 'Beginning, middle, end' model, which in project terms means 'What do we want to do? How are we going to do it? (then doing it) and How did we do?' Although not shown in all examples here, the phases within the lifecycle may overlap indeed planned overlap is one of the standard techniques used to speed up projects. Note that not every phase necessarily has milestone deliverables. The third example (from the top) given here is based on the PRINCE2 methodology, and the fourth example is from BAA PLC.
If the project is more of a blue-sky nature, or if you are dealing with the first kind and wish to make a thorough review of a pre-existing lifecycle model, the following is a checklist of questions to help you develop an appropriate phasing for your project:
Milestones, phases and stage gates
We have used the term 'milestone' above without defining it. A milestone is a special kind of deliverable or event that is an obvious marker that some piece of work, such as a phase of a project, has been completed the more obvious the better. An end of course exam is a paradigm case of a milestone: there is no doubt whether or not the exam has happened, it is a quite definite fact, and it is an event, rather than a drawn-out activity (if that seems untrue, then take the end of the examination as being the milestone).
Senior management often like to have project progress reports in terms of milestones. This has the advantage that if the milestones are well chosen, the reporting is simple and short but gives a good idea of progress. Milestones should be binary yes/no events. 'Have we delivered the prototype to the customer?', 'Does the database work?', 'Is the contract with suppliers signed yet?' and 'Have we been paid in full yet?' are all examples of milestone questions.
Milestones thus make natural boundaries to phases. This introduces the idea of scope, which we have seen is critical in project management. The scope of the project is simply a special term for the boundary of the project, so the boundary or scope of the overall project should align with the outer boundaries of the phases. This point sounds obvious, but may need to be remembered in large complex projects, or in smaller ones where what might look like a convenient milestone, because it is simple, has the unintended consequence of increasing the scope of the project. The difference between a final milestone of 'Deliver database' and one of 'Get paid' is an example of where this might matter.
Phasing in cost and risk control
Phasing can be used as a means to manage risk of wasted effort, poor coordination and unnecessary rework. These can arise in three ways:
Note that the design and use in a project of phasing and the type of lifecycle selected play a key role in managing each of these risks.
Phases to control when people start work
If you allow a child to choose which parts of cooking in the kitchen to attend to, you may find that the resulting meal is all chocolate cake and no vegetables or starter. In a more grown-up version, the same risks exist to your project, not only with individual people but also with suppliers and sub-contractors, who may feel strong incentives to start their work before your project is ready for it.
Suppose that a project has two phases apart from the 'beginning' and 'end' phases; let us call them M1 and M2. Suppose that M1 is tedious and dull, but that phase M2, which is very interesting and also fun to do, cannot be planned properly until phase M1 is finished. Both M1 and M2 are being staffed by project team members who are volunteering to do overtime. There is a risk that some of the team members, if left uncontrolled, will try to start work on M2 before M1 is finished, maybe even before M1 is started. A vital way to use the concept of the lifecycle in project management is to know when you have to say 'No this won't start until that has finished'.
You should understand what the logical sequence of work is and where there is a piece of work that should not start until some event has occurred. The Work Breakdown Structure focuses on this, and phasing can be used to enforce project discipline around critical no-start-before points. Make sure you understand the incentives which may exist in your project for people to start too early.
Front-end loading (FEL)
Front-end loading is the common sense idea of investing more in planning at the start of a project to avoid risk and cost later. This idea makes special sense in projects because changes are cheaper at the start of a project than at the end. Figure 2.7 (a) and (b) illustrates this point. When building a house, if we are going to change the shape of the foundations of the house, the time to do it is before the foundations are built, not after the roof is finished, because a change then means knocking the house down and starting again. So front-end loading is the formal name for a lifecycle approach that deliberately applies more planning, testing and development effort to the early stages of a project with the intention of reducing cost or risk later. It is often used in conjunction with stage gates.
Figure 2.7. Cost and probability of completion
(a) What a typical project looks like in terms of costs and risks, and to what extent its outcomes can be influenced
(b) As the project proceeds, risks reduce but the ability to influence its outcomes, and especially to change them, decreases
The main implication of FEL for phasing your project is that if your project uses FEL you may need to increase the number of early phases, or make the early phases longer, and in either case probably increase their budget. You should also include in the business case the case for using FEL and a justification for the extra costs to be incurred, that is, what specific benefits later on should be expected from the extra up-front costs. One implementation of FEL with stage gates is:
A key distinction: lifecycle versus project process groups
The next chapter describes project process groups. These are:
This list looks like a project lifecycle model, and while the words initiating, planning, etc. could be used as names for phases in a project lifecycle, this is not what the project management process groups are. It is vital to be clear on this distinction, and many people who pass the PMI's professional exams are confused on this point, even sometimes those who pass with high marks.
The lifecycle of a project is the way that it is broken up into different phases, and a project should have whatever phases are decided. It is definitely not the case that all projects should be forced into a lifecycle of 'initiate, plan, execute, monitor and control, close'. The project management process groups are doing something quite different from the phasing. The process groups describe what processes are more likely to be useful for initiating project management work, for planning it, and so on. When a project has a lifecycle of several phases, it is likely that many of the five process groups will be needed in each phase. The planning phase, if there is one, is likely to need rather more of the planning process group, of course, but even the manufacture phase (assuming there is one) may need some of the planning process group, especially if teething lessons in manufacture of the project's product necessitate revisions to the project plan.
In a project with a single phase, that is a project not broken down into phases, you are likely to want to use all the process groups in the project, which means using all five in one phase this example may help to make clear the difference between phases and process groups.
Phasing must vary according to the project type, and many industries and organizations have their own models for phasing. The project management process groups are collections of processes that are naturally likely to be used together, and potentially all five might be used in any one phase of the project. Whether any process group is actually used in a particular phase of a project will vary according to the specifics of the project. Why does this distinction matter? There are five reasons. Confusing the two:
If after reading the above you still feel confused, don't worry. Things should become clearer after reading the next chapter. If you are not intending to read the next chapter right away, all that it is essential to remember is that a project phase is absolutely not the same thing as a project management process group.
Project lifecycles and product lifecycles
Sometimes members of the project team may get confused between a product lifecycle and a project lifecycle. Note that these are two clearly and distinctly different things, although in the case where a project is creating or modifying a product, they are related to that extent. Suppose that Project Icarus is a project to design and build the Fantastic Large Aircraft (FLA). The contract for the project states that Icarus, the project, ends when the first FLA completes its airworthiness testing and gains a civil transport licence. The design and manufacture of the product, the FLA, and all maintenance of FLA, will be done thereafter not by project Icarus, but as a business line (that is, a process) within FLAC, the FLA Company. The FLA is expected to have a 50-year life, whereas the Icarus project is expected to last 10 years. The lifecycle of the FLA is longer than the Icarus project lifecycle, and the FLA starts life well after the Icarus project begins. This distinction is a very simple one, but it is worth watching out for confusion in your project team between the two, and being clear in communication with stakeholders when discussing either lifecycle about which one it is.
Note that the project lifecycle and the product lifecycle interact. As sponsor or project manager, you need to understand how they interact, not in a complex theoretical way but in a practical way. There will be processes related to the product that either will be part of your project or will interact with it. These are usually defined in the project lifecycle model. For example, in defence procurement in the UK, many processes related to creating products such as submarines and aircraft are defined in terms of the CADMID lifecycle. Managing the production of these products is a project (or programme) and uses project management.
Top of Page