Sensing Gap in Requirement Process in Software Maintenance work

Gartner predicts highest CAGR of 8.9% in Application Software Support Services in next 3 years. For any Software company engaged in off shoring, application support services provide continuous revenue stream and is very important piece of work. We often come across situations like lack of understanding of domain of the client. Domain plays a very important role in understanding the requirements, and their effective elicitation and interpretation. I have seen many projects going down due to flaw in the requirement process particularly in maintenance space. Sensing gap in the process at the early stage helps in making project successful.

This reminds me of a famous story of a surgery by a qualified doctor. A patient signed a contract with doctor. The patient was operated to remove gall bladder stones from his stomach. The gall bladder stones were picked up and shown to the near and dear of the family, they all were excited. When the patient came out, he was dead. The Doctor had signed for removing gall bladder stones. That was the requirement. It was never discussed that patient should recover after the operation. Can we consider such operations successful? Certainly not. This explains the type of requirements namely Explicit Requirements and Implicit Requirements. During requirement elicitation process, the explicit requirements are spelled out and the implicit ones are often missed out if the requirement team is not experienced in domain and in art of requirement gathering. Such situations lead to troubled project & troubled relationship. The question comes how do you sense such gap at early stages?

I will share some symptoms which should alert a project manager and should remind him to focus his attention to details and bring the best practices in requirement gathering for software maintenance work.

1. Waiting for Clarifications: When you dive deep into project review and come across situations of “Waiting for Clarifications”, get alerted. There is a very fine line between “Seeking Clarifications” & “Lack of Understanding”. Look into some specific situations. You may get surprise in terms of lack of knowledge of your team on the subject.
2. Low First time Right: First time right is an excellent metrics for measuring your maintenance ticket delivery to the customer. If your first time right is lower than 70%, look into the requirement process.
3. Low productivity of the team: The low productivity may be due to various reasons. One of the most important reasons is wasting time in interpreting requirement and getting into a loop of understanding.
4. Disagreement on CR Vs Defect during defect washing process: Sometimes customer can be unreasonable. But most of the times such situations arise due to gap in requirement understanding.
These are some of the indications. The moment you come across one or few of them in your project, look at the requirement gathering process under microscope. You will come up with one which is most suitable to your company in the given situation. However, I would like to share a few best practices in this area.

1. Most of the outsourcing engagements are structured as onsite-offshore engagement. Often an onsite co-coordinator is linked to the engagement. Giving requirement gathering task to onsite coordinator or business analyst is a good practice. He/she captures the requirements, gets validated with the customer and then shares with offshore team for understanding and development work. This process saves a lot of time and takes care of some of the symptoms mentioned above.
2. As mentioned earlier, domain plays a very important role in requirement interpretation. Let us take a look at domain skills of our team. Some generic knowledge with each team member and presence of at least some domain specialists is a great help. This practice has helped me in some projects. It can be stated as taking your boat from troubled waters to safe waters.
3. In some of the cases you may not be able to put a coordinator who is able to elicit requirements. It may be a good practice to explain requirements to the team including testers. This helps in open discussion and understanding the requirements by all team members. If any requirement clarifications are referred to the customer by the onsite coordinator. This helps in reducing gaps in requirement accuracy. Involvement of test folks at an early stage helps in delivering a quality deliverable.
I would argue – one of the very important roles of a Project Manager is to sense gap at an early stage of the requirement process. If you happen to see gap (Smoke), work towards finding out the root of the fire. It helps in extinguishing the fire and makes the project successful by following simple steps.