Managing IT projects, especially the development of software products, turned out to be more difficult than "classical" projects like in construction business. Nevertheless, in virtually every project we meanwhile have major portions of software development. Therefore, it is important to understand the main differences between an IT project and a "classical" one.
As presented in sub-section Project Management Models, a project managed in a more "classical" way follows a linear, step-by-step process: Somebody wants to have a certain product (e.g. custom built private home with 3 bedrooms and 2 bathrooms on one level), sets requirements for that product, works out a plan, and then implements the plan until the product is finished. To most of us it is clear that after a certain point or milestone in implementation we cannot easily change the design, i.e. requirements, without demolishing parts of the already existing structure and significantly re-building it (e.g. after finishing walls, ceilings, and roof change to: private home with 4 bedrooms and 3 bathrooms on two levels). Such changes would lead to considerable additional effort and cost which most of the customers (e.g. future home owners) could not tolerate i.e. be willing to finance.
On the other hand, in a typical software development project, we seem to be much less resistant towards the idea of changing the requirements. We consider software to be "soft" ware which is easy to change. So, why should it not be possible to change major requirements of that new accounting system, midstream of implementation, after 80 % of the whole package is already installed, tested, and verified? After all, we know from some best practice examples that software can be designed in a way that we can easily integrate changes in later project stages.
What project management model should we use in order to be able to cope with the challenges of changing requirements?
The first approach to solve that problem was the V-model, developed in the 1980s.
The V-model is an adapted waterfall model. It suggests establishing a close co-operation between
In sub-section Project Management Models, we indicated already that the spiral model represents an iterative approach of project management, suitable for managing IT projects. The spiral model actually emerged as an iterative software development method.
Iterative approaches have the advantage that we plan for changes; before we go into the first cycle of implementation we know that we will go back to defining requirements. Well, in fact, it is not like going "back". It is more like going through another round of defining requirements, but on a higher level, in terms of more knowledge and experience than the first time.
Thus, we obtain an evolutionary improvement of the requirements and consequently, of the results the project has to create. By applying the spiral model, we just acknowledge the fact that, at the beginning of planning phase, we are not really able to know all features, functionalities, and requirements or specifications the end product shall fulfill. The only question is then: For how many iteration cycles shall we plan? The answer depends on how long one cycle takes, and how much time we have in order to create a product that is acceptable by our stakeholders. That means that we have to communicate with our stakeholders, what is required, what is acceptable, what is nice to have, etc.? So, continuous communications between the project team and all project stakeholders becomes essential for project success. For managing IT projects, project planning and controlling tools will be similar, if not the same, as for "classical" projects.