Joint Requirement Discovery

Requirement management is the essence of Project’s Success. In simple words, it means that most of the problems that the projects encounter could have been avoided from the very begining by making it very simple and to understand the Customer’s expectations from the respective projects. Very often we hear the story of changing requirements. I was going through a project review; I came to know that the requirements were changing very often. May be that is a truth. But when we hear the customer’s side of the story you often get a different perspective. Customer often thinks that development teams lack the domain understanding and the ability to interpret requirements. There is always a fine line between understanding of requirement and seeking clarifications from customers. When you come across a story of frequent change in requirements and many requests for pending clarifications, it is time to look at your requirement elicitation process.

There are different stake holders in the Project. They view the requirements differently. They all may be right in their respective perceptions but collectively going by their understanding of requirements one cannot deliver a project to meet all their understanding.It reminds me of a very famous story of “Six Blind Men and the Elephant”.

Once upon a time, there lived six blind men in a village. One day an elephant came to the village. They had no idea what an elephant is. They decided, “Even though we would not be able to see the elephant, let us go and feel the elephant by touching it”. Each of the blind men touched the elephant. Perceptions emerged about the elephant. Hey, the elephant is a pillar," said the first man who touched his leg. "Oh, no! It is like a rope," said the second man who touched the tail. "Oh, no! It is like a thick branch of a tree," said the third man who touched the trunk of the elephant. "It is like a big hand fan" said the fourth man who touched the ear of the elephant. "It is like a huge wall," said the fifth man who touched the belly of the elephant. "It is like a solid pipe," Said the sixth man who touched the tusk of the elephant.

I think requirement process is very similar to the process of six blind men feeling the elephant. The designer, the developer, the tester and the user perceive the requirement differently. They are touching the requirements at a different point of time. They carry different perceptions and often get into a conflict about the requirement. Think of the situation where the six blind men had reconciled their respective observations. Obviously, a holistic picture about the elephant could have emerged.

Therefore it helps if different stakeholders sit together after their initial feel, reconcile their understanding and then come up with a unified view of the requirement. A simple three step process may be very useful in rationalizing requirements:
1. Every Stakeholder studies the requirement separately. They are Designer, Developer, Analyst, Tester etc
2. They come with their findings and questions and sit and discuss their understanding. Reconcile them and finally put a unified understanding to the customer.
3. Customer validates and rationalize the requirements.

These simple steps can avoid a confusion which crops in at a later state. Although these steps are simple and do not require great processes, we rarely implement them. These steps can be implemented in different flavor across different development methodologies.

These are Simple fundamentals but it works.

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.