Projects can be anything: a capital facility, an information system, a piece of research, a company merger, an organizational change, launching a product, or decommissioning a facility, and so on. They can range from capital intensive technological and infrastructure investments to labour‐intensive health care. All projects types need a description, a scope, and the associated specifications for the quality required, and they cannot be realized without a team of people to develop them. The fundamental characteristic of all projects is that they create and cause change. As such, they come up against resistance. Consequently, leadership is needed in the form of a project manager, and a project management process is required to control them. (See Section B.)
There is a hierarchy to projects determined by their size, complexity, and the inherent risks (see Figure I.A.1). At the lowest hierarchical level are the routines, tasks that are so common and so well developed in a function that methods of working have ironed out all the difficulties. Next in the hierarchy are those frequently occurring packages of work – small projects that are very similar and can be developed without too much specialized management and theoretically do not present any significant risks. There are lots of them in an organization and they can be performed without any real difficulty. These are called the runners.
At the next level of the hierarchy are larger projects that the organization performs reasonably regularly; they are very similar or replicate previous projects. Naturally, they are called repeaters. The development of repeaters has become more specialized, less routine, and more individually project‐focused. As a consequence they have a higher risk of failure. They need someone experienced in project management because the real risk with them is that people assume they are repeats. The reality is that they have differences that, if ignored, could cause project failure. Then come the projects that are infrequent and more unusual, they become strangers to an organizations normal method of working. They are large projects and are high risk projects as far as the organization is concerned. As a consequence, they need someone to manage them, who is skilled and experienced in project management. Finally, the mega project, the first of a kind, the once‐in‐a‐career opportunity are the aliens, consisting of a programme of large projects. (Part II addresses programme management).
‘Every project begins on paper as an ideal, as a vision of perfection and quickly becomes mired in the confusion of budget, size and opposition of NIMBY’s'. 2 Consequently, the best way to start a project is to carry out a feasibility study that results in a clear brief and statement of the requirements (see Part III). Nevertheless, there are features that are common to all projects regardless of size.
A primary characteristic of projects: a product, a development, a task, or a deliverable is that they are unique and are non‐repetitive.
Secondly, because projects start with a unique idea or concept, they go through a series of growth phases in order to achieve an outcome.
Projects are risky due to the very uniqueness of their nature. The risks are then compounded by the changes that can occur during the project's development. The severity, impact and consequences of the risks incurred are related to the hierarchical position of the project, as described above.
Projects come into being because they will provide benefits to an owner and a return on their investment; they have a purpose. The business requirements of a project become the owner's objectives. They then get translated into specific objectives for the management of the project (see Section B).
Projects almost invariably change in scope, often by very large factors, due to changing business requirements and market conditions.
It is typically necessary to reduce the costs involved in order to make the project financially viable and to make the business case acceptable. This will usually mean reducing the scope or specification of the project – see Figure I.A.2. Everyone creating a project has big ideas, but when the budget can't get any bigger, the ideas have to get smaller.
Clients may have limited funds and reduce the budget, but they do not reduce their ambition. In reality, there is no such being as a client who does not make changes. Thus, once the project is approved and has got the go‐ahead, there is a natural tendency to want to put back all the features that were removed. These changes are then likely to cause failure of the business objectives. Sometimes it can be almost impossible to match the requirements with the money that has been allocated to a project. This often occurs in the public sector. The correct approach is to deliver the essentials and, if there is anything left in the budget, add the ‘nice to haves’ when the essentials have been completed.
The development of a project is modelled by a series of phases or stages. Sometimes the phases they go through are carried out sequentially, but more often they overlap significantly. There are three basic project stages:
The conceptual, creative, thinking phase is a natural process; people enjoy it. The same is true of doing. People like to design, make, and construct – doing is also a natural process. This is not true of planning. Planning is not a natural process. It is imposed on a project's development by the management process. The trouble is that people's natural desire is to jump straight from the thinking stage to the doing stage. If this occurs, project disaster is guaranteed. It is not a flaw in the characteristics of projects; it is a failure in a project's management.
For more complex situations, these basic phases are broken down into more detail. Between each phase, there is an opportunity to assess the viability of the project and decide if one wishes to proceed to the next phase. The objective of breaking the project into phases is to enable one to plan and control the work at the appropriate level of detail.
The following Figure I.A.3 is a basic model of a typical project, showing the state of development for each phase of the project. These phases are typical for technological projects such as the process and power industries 3 , but it is also intended to be generic:
Figure I.A.4 shows the different terminology and phase definitions used in different business environments:
There are three positions in the development of the phases where the owner may contract with someone else to perform the work in subsequent phases:
The purchasing options available to the owner mean that the stages in Figures I.B.3 or I.B.4 involved in the contracting process have to be integrated into phases shown in Figure I.A.4.
There are important patterns that depend on the phases of the project and give a clearer understanding of the way a project develops.
During the feasibility study, alternative types of projects are being examined, and by the time the final study is accepted by management, the cost of the work is known to within a reasonable margin. Assuming the basic concept does not change, it is extremely difficult and often impossible to make more than a 15 per cent saving. In other words, 85 per cent of the cost impact has been determined during the front end phases (See Figure I.A.5).
The financial commitment in the early stages of the job is very small compared with the costs once production work commences. It is much cheaper to totally change the approach to the project during the feasibility study phase when all that is involved is a new report than to make a change later when major equipment has been bought and work has started on site. This illustrates why it is important to have the best brains available during the early phases of the project (See Figure I.A.6).
There are five reasons for doing projects:
Projects cannot accomplish anything on their own. To survive they have needs that must be met. Namely: