Changing Customer Requirements

Most of the times, the requirements from an organization are communicated by a business person to the IT / development teams. This often leads to ambiguity and miscommunication. One of the main reasons for this is that the business side of any organization is not interested in the technical aspects of it. Also the technical teams do not see the business aspects of a solution and are already thinking which technology would be most suitable for implementation. To add to the complexity, in most cases the requirements keep changing during the entire project life-cycle. Lack of agreed scope and requirements documentation also adds to the scope creep. This leads to re-work, increase in cost, and sometimes, low software quality. Add to this unsatisfied business and IT teams the result is a failed project and waste of investments. This may also drain the team’s motivation and cause an irritable atmosphere to work in. Another aspect of the scope creep is, when the clients / business change the scope of the project at the later stage of the project, IT teams would have to re-work the scope and estimates which will also led to a delay in the project timeline.

It is important that the team decides on a strategy to tackle these changing requirements and follow it throughout the project lifecycle for efficient time and resource utilization.

Some of the techniques to manage changing requirements are described below:

1. Spend more time on requirements gathering: It is advisable to spend ample amount of time on requirement gathering activity because it is important to discuss and finalize all the requirements in detail at an early stage. The requirements must be agreed upon by all stakeholders and the development / business analysis team. This ensures enough time for brainstorming on requirements and fewer changes in the future. Also get a sign off from all the stakeholders on the final scope of the project. This ensures that when the teams members are replaced any future confusion can be avoided
2. Freeze requirements: This would be a logical conclusion of the earlier point. At some point in the project lifecycle, the requirements must be frozen. Goes without saying the earlier the better! It must be communicated to the business / clients that any changes / additions in the requirements after the frozen date will be tackled later as a part of enhancement or phase II. This action is very effective for the project team and helps in smooth driving of the project. This also helps in better resource management and teams can focus on the task at hand rather than worry about additional functionalities creeping in. Scope creeps apart from hampering resource utilization also have a demoralizing effect on the teams.
3. Create /Track the project plan: Sometimes, there may be changes which cannot be avoided or delayed to the next phase. In such situations, the project team must try and include these requirements in the most cost efficient way, avoiding much delay in the project timeline. It is beneficial to create a plan before hand to deal with such kind of requests. One mistake many teams may make is to have a plan for the entire project but failing to track it. Creating a plan is the very first step but it cannot stop at that. Tracking the progress against the plan is very important so that delays can be highlighted and steps can be taken to reduce the impact.

Changing customer requirements can become a very troublesome aspect of any project. Though the reasons for changes in requirements can be justified in some cases, it causes many problems and delays in the lifecycle of the project. It is therefore important to tackle changing customer requirements by formulating a proper strategy to avoid any loss or delay in the project.

About Author:
Amol Bhembre is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: amol.b@spluspl.com