Project lifecycle

Introduction

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.

Table 2.5. Examples of key differences in focus for project management at different phases of the project, on the simplest of all lifecycle models

Beginning	Middle	End
Acceptable right at the start not to know exactly what the aims, rationale and approach of the project are, though these should be worked out early on.	Must be clear on what the aims, rationale and approach of the project are.	The only thing that matters is: did the project achieve the aim?
The right time to work out what the plan is.	Should be following the plan and doing the work.	The plan is irrelevant. Lessons learned should be captured and applied to future projects.
Acceptable not to know who will be doing the work and how they will be organized, but should be worked out early on.	The project team should have bonded and formed as a team, with its own distinct style. Some changes to team members are normal.	The project team breaks up and individuals return to their line roles or move on to other projects.

PMI says

Project lifecycle and project phase

'Project Lifecycle. A collection of generally sequential project phases whose names and number are determined by the control needs of the organization or organizations involved in the project. A lifecycle can be documented with a methodology.' PMBOK Guide (p.368)

'Project Phase. A collection of logically related project activities, usually culminating in the completion of a major deliverable. Project phases ... are mainly completed sequentially, but can overlap in some project situations. Phases can be subdivided into subphases and then components; this hierarchy, if the project or portions of the project are divided into phases, is contained in the work breakdown structure. A project phase is not a project process management group.' PMBOK Guide (p.369)

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:

• Either your project will be of a kind for which there is an established model, perhaps one created by your organization for its own particular needs, or created by a professional body, or there may be a model available informally which can be understood by talking to someone who has done similar projects before.

• Or the project will be of a 'blue sky' nature, that is, something that has not been tried before, in which case how to phase it and what the lifecycle options are will be one of the earliest tasks and can be a major undertaking or sub-project in its own right.

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.

 

Some lifecycle models

Spiral development

Spiral development is one of many responses to the problem of costs and time overruns in project management in defence and other industries. It aims to overcome three problems:

• Cycle time/obsolescence rapid advances in technology mean that as the project progresses, new working methods and new solutions become available that could not have been foreseen at the start, creating a risk of building something obsolete. The business need is to speed up the cycle time.

• Interfacing the problem of how different organizations with different approaches to project management, including different lifecycle models, can work together on joint projects efficiently.

• Waste the particular risk of waste that arises when a project progresses too far without checking that what it is doing is actually what is wanted and is valuable.

Spiral development is a new name for an old idea, which can be summed up as 'build a little, test a little'^[4]. The US Department of Defense has indicated a definite preference for spiral development in certain areas^[5] and its websites contain further information. An alternative starting point for further information is the Software Engineering Institute of Carnegie Mellon University (CMU)^[6].

CADMID

The CADMID cycle used in UK defence procurement is aimed at achieving the same things. Although the CADMID cycle is most popular in defence procurement and contracting, it embodies practical principles which can reduce risk and cost in a wide variety of industries such as capital markets, pharmaceuticals, government, software and financial services. Three notable features of the CADMID cycle, which may be worth considering as potentially significant factors in designing the phasing of your project, are as follows.

• Work out the concept first. Written down in CADMID form, this looks obvious, but unless the separation between working out the concept of a new product or service on the one hand and creating and delivering it on the other is made explicit, then there is a greater risk of problems in cost, work control and stakeholder miscommunication.

• Demonstrate before full-scale production. Having a demonstration or trial phase specifically to learn about the project's product reduces risk and cost later on. This can be unpopular with senior stakeholders who are under pressure to deliver results soon, but experience shows that often in projects that intend to deliver new technology or new services, more haste results in more cost and less speed, and a thorough demonstration phase, separate in scope and prior to main production, is almost invariably a sound idea.

• Plan for retiring the product. If the project produces something that will be integral to the organization's business processes, then when the time comes to retire the product, another project will be necessary. Retirement need not be part of the project that creates the product, but it will be valuable in the long term when creating the new product or service to capture and store information likely to be critical when retiring the product or service. The biggest example in recent times of not doing this was in the software industry where many pieces of software had to be retired in preparation for the year 2000 but to do so incurred great cost because much of the knowledge necessary for safe, controlled retirement of that software from the mission-critical processes had been lost. This is an example of the importance of knowledge and information management in project and programme management, but that is a subject beyond the scope of this book.

Business process reengineering

A number of methodologies have been developed for doing business process reengineering, most of which are based in some way on the work of Michael Hammer^[7]. Most of the major management consulting firms, such as IBM Consulting, have their own flavours of business process reengineering, and many large commercial and government organizations are following this trend.

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:

• How will you know when you have finished the project? What are the success criteria? What will success look like? What will it have delivered or how will the world be different?

• What are the 'exam questions' that your project has to answer? Or that you have to answer before the project can proceed?

• What is the logical structure of your project, in terms of sequence of work?

• Who are the key stakeholders, and what do they expect the product to produce from their point of view?

• What are the implications for phasing of cashflow or budget factors? And of your financial year cycle?

• What are the key deliverables? What implications could they have for phasing?

• If you will bring into the project sub-contractors or different teams of people, will their arrival and departure be potential phase boundaries?

• What regulatory or legal compliance tests have to be met? Should these define phase boundaries?

• What degree of front-end loading (FEL) should your project have? (FEL is explained on page 57.)

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).

PMI says

Milestone

'Milestone. A significant point or event in the project. ...' PMBOK Guide (p.364)

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:

• people who want to do work at the wrong time (too early or too late to be of maximum value);

• the natural tendency of cost of changes to increase and probability of completion to increase with project progress; and

• not understanding early enough in the project key details.

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:

1. Concept approved.

2. Feasibility proved.

3. Definition finalized.

4. Pre-operational installation and commissioning.

5. Operational commissioning.

A key distinction: lifecycle versus project process groups

The next chapter describes project process groups. These are:

1. Initiating.

2. Planning.

3. Execution.

4. Monitoring and control.

5. Closing.

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:

• limits your ability to exploit for your project the value built into a lifecycle model if one exists, or to design an optimal lifecycle model;

• limits your ability to get maximum benefit from project management tools and techniques, such as the PMBOK;

• may weaken your credibility as a project manager with key stakeholders;

• creates extra and unnecessary work and risk in reconciling the two in areas where no reconciliation is necessary; and

• increases risk by reducing the range of tools and techniques you may consider applying in any phase of the project.

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