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 Seven
Maintenance Stage
Although it is extremely important, the Maintenance Stage is often neglected. During this stage, everything is arranged that is necessary to bring the project to a successful completion. Examples of activities in the Maintenance Stage include writing handbooks, providing instruction and training for users, setting up a help desk, maintaining the result, evaluating the project itself, writing the project report, holding a party to celebrate the result that has been achieved, transferring to the directors and dismantling the project team.
The central question in the Maintenance Stage concerns when and where the project ends. Project leaders often joke among themselves that the first ninety per cent of a project proceeds quickly and that the final ten per cent can take years. The boundaries of the project should be considered in the beginning of a project, so that the project can be closed in the Maintenance Stage, once it has reached these boundaries.
It is sometimes unclear for those concerned whether the project result is to be a prototype or a working product. This is particularly common in innovative projects in which the outcome is not certain. Customers may expect to receive a product, while the project team assumes that it is building a prototype. Such situations are particularly likely to manifest themselves in the Maintenance Stage. Consider the case of a software project to test a very new concept.
There was some anxiety concerning whether any results would be produced at all. The project eventually produced good results. The team delivered a piece of software that worked well, at least within the testing context. The customer, who did not know much about IT, thought that he had received a working product. After all, it had worked on his office computer. The software did indeed work, but when it was installed on the computers of fifty employees, the prototype began to have problems, and it was sometimes instable.
Although the programmers would have been able to repair the software, they had no time, as they were already involved in the next project. Furthermore, they had no interest in patching up something that they considered a trial piece. Several months later, when Microsoft released its Service Pack 2 for Windows, the software completely stopped functioning. The customer was angry that the product once again did not work. Because the customer was important, the project leader tried to persuade the programmers to make a few repairs. The programmers were resistant, however, as repairing the bugs would cause too much disruption in their new project. Furthermore, they perceived the software as a prototype. Making it suitable for large-scale use would require changing the entire architectural structure. They wondered if the stream of complaints from the customer would ever stop.