4.2 Project life cycles
Earlier I said that a project is: 'a unique venture with a beginning and an end' (Boddy and Buchanan, 1992, p. 8). But it must have a middle, too. We say that a project has a 'life cycle'. This is based on an analogy with living things which are born, live for a period of time, doing things like consuming food and water, breathing, moving, etc., and then finally end (die). There is much discussion about whether there is only one 'true' model of a project life cycle or many, and whether any of these are reasonably accurate descriptions of what happens in real life. Some writers include the feasibility study as part of the project life cycle; others believe that the project proper only begins once the feasibility study is completed and the proposal accepted, or when cost headings for the project are defined. I will use proposal acceptance, since management normally give approval after they have been presented with the feasibility study and decided to go ahead with further work. If you find it helpful, think of the work needed to carry out a feasibility study as being a mini-project in its own right.
Even with the best of plans and most stringent of controls, real life is always more chaotic than the models we apply to it; the same is true to projects. Nevertheless, in the case of projects, models are useful to help us recognise different ways of moving from the project's beginning to its end, and the broad phases where the activities that take place change from one type to another.
There is no single life cycle that applies exactly to all projects but there are enough similarities for me to consider a basic project life cycle, adapted from a five-phase model described by Weiss and Wysocki (1994). In doing so, I have adopted a somewhat different terminology here from that which has been commonly used in the past. The basic project life cycle is shown in Figure 8 as a series of arrows proceeding from definition to closure.
The overlapping areas between the major phases of work in Figure 8 show that the change from one phase to the next is not abrupt: in many projects activities that seem to be part of the planning phase can overlap with activities from the organising phase, and so on.
Proposals are formulated, estimated and tested for feasibility, and sufficient plans are made to enable a 'go/no-go' decision to be made, often in the form of a contract. The decision forms the end of the stage often called the 'definition phase'. Many writers refer to this as the 'feasibility phase'.
Once a decision to go ahead has been made, a project enters a 'planning phase'. Some plans and general costs, of course, will probably have emerged from the definition phase. However, these earlier plans and cost estimates will have been developed simply to enable a decision to be made about whether to pursue the proposal further, not to plan its execution in detail. Much more refined figures are now needed.
The major tasks that must be carried out in the planning phase include:
task identification and sequencing;
identification of activities critical to success;
estimating and budgeting;
staffing.
By the end of the planning phase, work can begin on the 'organisation phase'. Some or all of this phase may overlap with the planning stage. The aim during the organisation phase is to put in place the teams, controls, tools and communications that will be required for the next phase.
The next phase is 'execution', or 'implementation'. The important activities in this phase are:
communicating with management, client, users and others;
reviewing progress;
monitoring costs;
controlling quality;
issuing orders for change;
managing changes.
This phase comes to a close as the agreed deliverables are installed.
The final stage of the project is the 'closure phase'. The results of the project can then be put into operation.
When there is significant overlap in time between activities in different phases, for example when planning activities continue at the same time as organisation is under way and execution may even have begun, we say that these activities exhibit 'concurrency'. Since changes are an inevitable fact of project life, there will also be times when activities such as estimating or even recruiting or assigning work have to be done again in response to such changes.