Dividing a project into stages makes it possible to lead it in the best possible direction. Through this organization into stages, the total workload of a project is divided into smaller components, thus making it easier to monitor. The following paragraphs describe a staging model that has been useful in practice. It includes eight stages:
Stage 1 : Initial Stage
Stage 2 : Identification Stage
Stage 3 : Critical Analysis Stage
Stage 4 : Structuring Stage
Stage 5 : Project Development Stage
Stage 6 : Execution Stage
Stage 7 : Maintenance Stage
Stage 8 : Ongoing Management Stage
Stage Six
Execution Stage
The project takes shape during the Execution Stage.
This Stage involves the construction of the actual project result. Programmers are occupied with encoding, designers are involved in developing graphic material, contractors are building, the actual reorganization takes place.
It is during this stage that the project becomes visible to outsiders, to whom it may appear that the project has just begun.
The Execution Stage is the doing stage, and it is important to maintain the momentum.
In one project, it had escaped the project teams attention that one of the most important team members was expecting to become a father at any moment and would thereafter be completely unavailable for about a month. When the time came, an external specialist was brought in to take over his work, in order to keep the team from grinding to a halt. Although the team was able to proceed, the external expertise put a considerable dent in the budget.
At the end of the Execution Stage, the result is evaluated according to the list of requirements that was created in the Identification Stage. It is also evaluated according to the structuring designs.
For example, tests may be conducted to determine whether the web application does indeed support Explorer 5 and Firefox 1.0 and higher.
It may be determined whether the trim on the building has been made according to the agreement, or whether the materials that were used were indeed those that had been specified in the Identification Stage. This stage is complete when all of the requirements have been met and when the result corresponds to the structuring design.
Those who are involved in a project should keep in mind that it is hardly ever possible to achieve a project result that precisely meets all of the requirements that were originally specified in the Identification Stage. Unexpected events or advancing insight sometimes require a project team to deviate from the original list of requirements or other design documents during the execution of the project. This is a potential source of conflict, particularly if an external customer has ordered the project result. In such cases, the customer can appeal to the agreements that were made during the Identification Stage.
As a rule, the requirements cannot be changed after the end of the Identification Stage. This also applies to structuring designs: the structuring design may not be changed after the Structuring Stage has been completed. Should this nonetheless be necessary (which does sometimes occur), the project leader should ensure that the changes are discussed with those involved (particularly the decision-makers or customers) as soon as possible. It is also important that the changes that have been chosen are well documented, in order to prevent later misunderstandings. More information about the documentation of the project follows later in this handbook.