This chapter provides a sketch of the traditional method of project management.
The model that is discussed here forms the basis for all methods of project
management. Later chapters go into more depth regarding a model that is
particularly appropriate for IT-related projects.
Dividing a project into phases makes it possible to lead it in the best possible
direction. Through this organisation into phases, the total work load of a project is
divided into smaller components, thus making it easier to monitor. The following
paragraphs describe a phasing model that has been useful in practice. It includes
1. Initiation phase
2. Definition phase
3. Design phase
4. Development phase
5. Implementation phase
6. Follow-up phase
The initiation phase is the beginning of the project. In this phase, the idea for the
project is explored and elaborated. The goal of this phase is to examine the
feasibility of the project. In addition, decisions are made concerning who is to carry
out the project, which party (or parties) will be involved and whether the project
has an adequate base of support among those who are involved.
In this phase, the current or prospective project leader writes a proposal,
which contains a description of the above-mentioned matters. Examples of this
type of project proposal include business plans and grant applications. The
prospective sponsors of the project evaluate the proposal and, upon approval,
provide the necessary financing. The project officially begins at the time of
approval. Questions to be answered in the initiation phase include the following:
Why this project?
Is it feasible?
Who are possible partners in this project?
What should the results be?
What are the boundaries of this project (what is outside the scope of the
The ability to say ‘no’ is an important quality in a project leader. Projects tend to
expand once people have become excited about them. The underlying thought is,
’While we’re at it, we might as well …’ Projects to which people keep adding
objectives and projects that keep expanding are nearly certain to go off schedule,
and they are unlikely to achieve their original goals.
In the initiation phase, the project partners enter a (temporary) relationship
with each other. To prevent the development of false expectations concerning the
results of the project, it makes sense to explicitly agree on the type of project that
is being started:
a research and development project;
a project that will deliver a prototype or ‘proof of concept’;
a project that will deliver a working product.
The choice for a particular type of project largely determines its results. For
example, a research and development project delivers a report that examines the
technological feasibility of an application. A project in which a prototype is
developed delivers all of the functionalities of an application, but they need not be
suitable for use in a particular context (e.g. by hundreds of users). A project that
delivers a working product must also consider matters of maintenance, instructions
and the operational management of the application.
Many misunderstandings and conflicts arise because the parties that are
involved in a project are not clear on these matters. Customers may expect a
working product, while the members of the project team think they are developing
a prototype. A sponsor may think that the project will produce a working piece of
software, while the members of the project team must first examine whether the
idea itself is technically feasible.