After the project plan (which was developed in the initiation phase) has been
approved, the project enters the second phase: the definition phase. In this phase,
the requirements that are associated with a project result are specified as clearly as
possible. This involves identifying the expectations that all of the involved parties
have with regard to the project result. How many files are to be archived? Should
the metadata conform to the Data Documentation Initiative format, or will the
Dublin Core (DC) format suffice? May files be deposited in their original format, or
will only those that conform to the ‘Preferred Standards’ be accepted? Must the
depositor of a dataset ensure that it has been processed adequately in the archive,
or is this the responsibility of the archivist? Which guarantees will be made on the
results of the project? The list of questions goes on and on.
Figure 2: Expectations of a project (Illustration: Rachèl Harmsen)
It is important to identify the requirements as early in the process as possible.
Wijnen (2004) distinguishes several categories of project requirements that can
serve as a memory aid:
Preconditions form the context within which the project must be conducted.
Examples include legislation, working-condition regulations and approval
requirements. These requirements cannot be influenced from within the project.
Functional requirements are requirements that have to do with the quality of the
project result (e.g. how energy-efficient must an automobile be or how many
rooms must a new building have?). Operational requirements involve the use of the
project result. For example, after a software project has been realised, the number
of malfunctions that occur must be reduced by ninety per cent. Finally, design
limitations are requirements that involve the actual realisation of the project. For
example, the project cannot involve the use of toxic materials or international
partners for whom it is unclear whether they use child labour.
During the definition phase of a project that involved developing a web application
for a consortium of large organisations, no agreements were made concerning the
browser that would be supported by the application. The consortium assumed that
it would be Microsoft Explorer, because it was the browser that ‘everyone’ used.
The programmers created the application in Firefox, because they worked with the
browser themselves and because it had a number of functions that were
particularly useful during the development. Because most of the websites that are
made for Firefox also look good in Explorer, the difference was initially not
noticeable. Near the end of the project, however, the customer began to complain
that the website ‘didn’t look good’. The programmers, who had been opening the
site in Firefox, did not understand the complaint.
When the problem of the two browsers became clear, the programmers reacted
defensively, ‘Can’t they just install Firefox? After all, it is free’. The organisations,
however, were bound to the bureaucratic-minded system administrators who, for
some possibly justified reason, refused to install Firefox in addition to Explorer.
Even if they had wanted to install it, it would have involved a lengthy process, and
there would have been extra costs for the time that the system administrators
would have to spend on the task. It was ultimately decided that the application
would have to be made suitable for Explorer. That involved considerable extra
work, whereby the project ran even more behind schedule than it already had, and
it was necessary to negotiate the extra costs. It was later discovered that the
various organisations were working with different versions of Microsoft Explorer.
It is very important that all parties that are involved in the project are able to
collaborate during the definition phase, particularly the end users who will be using
the project result. The fact that end users are often not the ones that order the
project perhaps explains why they are often ignored. The client, who pays for the
project, is indeed invited to collaborate on the requirements during the definition
phase. Nonetheless, the project result benefits when its future users are also
invited. As a point of departure, it is helpful to make a habit of organising meetings
with all concerned parties during the definition phase of a project.
Project Management Handbook, version 1.1
During the development of an educational video game, the users (young people)
were involved in the project only at a later stage. When the game was nearly
completed, a group of young people was asked to test the game. Their initial
assessments appeared mild and friendly. When pressed, however, they admitted
that they had actually found the game ‘extremely boring’ and that they would
‘certainly not play it themselves’. Had these young people been involved in the
project earlier, the game would probably have been a success. As it stands, the
game remains nearly unused on an Internet website.
The result of the definition phase is a list of requirements from the various parties
who are involved in the project. Every requirement obviously has a reverse side.
The more elaborate the project becomes, the more time and money it will cost. In
addition, some requirements may conflict with others. New copy machines are
supposed to have less environmental impact; they must also meet requirements for
fire safety. The fire-safety regulations require the use of flame-retardant materials,
which are less environmentally friendly. As this illustration shows, some
requirements must be negotiated.
Ultimately, a list of definitive requirements is developed and presented for the
approval of the project’s decision-makers. Once the list has been approved, the
design phase can begin. At the close of the definition phase, most of the
agreements between the customer and the project team have been established.
The list of requirements specifies the guidelines that the project must adhere to.
The project team is evaluated according to this list. After the definition phase,
therefore, the customer can add no new requirements.
A part of a new exhibit in a museum was comprised of a computer installation, the
creation of which had been project-based. Because there had been no definition
phase in the project, no clear agreements between the museum and those
responsible for building the installation had been made. When the computer for the
installation broke down halfway through the exhibit, the museum assumed that it
would be covered by the project’s guarantee. The project team had a different
opinion. Negotiations between the directors were necessary in order to arrive at an