A project manager must avoid making unnecessary changes once a design has been finalised, to prevent the project from disastrous consequences, warns Dr R Srinivasan

It is a well known fact that before designing, we should be aware of the requirements and specifications of the end product which would direct the plan and methodologies to finalise the design aspect. As a rule, once the requirements are thoroughly discussed, analysed and finalised with the customer, any additional requirement should not be entertained unless they are very essential and were left out in the earlier discussions by oversight. However, new requirements should not be piled on; this will not only make the design process tedious but will also affect every stage in the planning process, resulting in both schedule overrun and efforts. The ultimate result is that the project will become catastrophic.

The antipattern under this type of activity is called "Gold Plating or Gliding the Lily". The obvious question is, how such a thing can happen, particularly when all aspects of software development processes are well- defined. The situation may arise because of the customer or software development organisation, when new ideas come in or suggestions for improvement are administered. In this situation, it is the responsibility of the project manager to recognise good ideas and genuine suggestions if they are appropriate, but at the same time keeping in mind the objectives of the project. Sometimes, it may happen that a major functionality has been missed out and discovered later. In such cases, it is advisable to take the concurrence of the customer so that they can be incorporated in the next version rather than going back to square one. As William Brown says, the missed functionality is not the case of "Gliding the Lily", whereas the concern is the functionality or design attributes which are unnecessarily compelled to be incorporated in the design.

This type of antipattern happens not because of any ill intention of those who suggest it, but for adding better features in the final product and is hence a positive suggestion. This will put the project manager into a state of confusion because he will recognise that these people are not malicious, and particularly so if they are the stakeholders in the project. Experts in software development and processes identify that the parties who contribute to this antipattern are the management of the software organisation developing this project, the software architect, members of the project development team and even the customer.

The management of the organisation may be involved because though outside the project, they are part of the overall review team who have too little to do, or have prior experience in software development in any capacity, or are not directly in the main stream of management, or might have been part of the customer community, and above all may be over enthusiastic about the project.

In any case, they are not directly involved with the project and hence would not bother about other problems, which would affect the schedule and hence the cost. The project manager will be put in an embarrassing position and he cannot avoid this because others try to overshadow him. Hays McCormick draws a parallel and says that this definitely is a landmine for the project manager and it is very difficult for him to work his way through the situation.

The second category that gets the project into the "Gliding-the-Lily" antipattern is the customer. This is yet another difficult situation for the project manager because of beliefs like, "The customer is the king", "The customer is always right", or "The customer must be kept happy always". From the customer or the user side, he will aim at only what he wants, unmindful of the changes to be made and the repercussions therein. However, it is the responsibility of the project manager to be persistent and advise the customer of the possible impacts of the changes to the system and point out that the original requirements have been discussed and base-lined at the initial stage itself. In a similar manner, once the architecture is finalised and base-lined, the project manager should see to it that the software architect does not introduce changes at this stage.

The fourth category responsible for creating this antipatten are the developers in the project team. This is the most challenging one for the project manager because it may be transparent to him and hence difficult to detect. This should be avoided by making the developer stick to the stipulated requirements only and not add anything during development. This will be controlled through very rigorous and periodical reviews supported by a good configuration management.

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)