Another scope change request arrived this week. And how many of them have already arrived so far? 4, 10, …?
Why do customers constantly change their requirements? Is it indecision, lack of definition or the result of a bad requirements elicitation?
In this blog, I will present some tips that we use at Intraway for a good requirements elicitation and thus, to get a clear definition of the scope of a project.
Why do scope change requests arise?
Every project is born from a “stimulus”, such as the need for a business, market demand, profit, technological advances, legal and social requirements, among others.
The reason of life of a project, however, may be subject to change over time. In three months, for example, there may be a new technology that requires us to adapt the direction that we had planned. In this context, changes are completely valid, substantiated and necessary to ensure that the product/service we are building has value to the customer.
But, what happens with those requirements that were not gathered at first, but that already existed in the client’s head, those hidden requirements that come to light after the project has advanced? These are the changes that we must avoid, because all change has an associated cost.
The aim of a good Requirements Elicitation, and our goal as functional analysts, is to achieve consensus with the client about the scope of the project (what will be included in and excluded from the project), avoiding gray areas and misunderstandings.
The importance of a good Requirements Elicitation
The process to collect requirements is essential to define clearly and precisely the scope of a project. Ambiguous or incomplete requirements will result in a poor project scope statement, bringing with it a barrage of requests for changes.
A good requirements elicitation contributes to:
- Achieving project success: incomplete or changing requirements are a major factor of failure in a project. If it is not clear what I have to do, how can I make an estimate of costs and time? What acceptance criteria will be used to evaluate a product/service and determine whether achieved the desired level of satisfaction?
- Avoiding Gold Plating: Gold Plating is the phenomenon by which more functionality than the one requested by customer is delivered, as decided by the project team. Why is Gold Plating wrong? Because this extra functionality, considered an “improvement” for the team, could affect the expected behavior of the solution, increasing the risks and diverting the focus of what really has value to the customer. Gold Plating could also affect planned deadlines and costs. What if the solution is not delivered on time by adding extra work, not required by the customer? My recommendation is to analyze jointly with the customer all opportunities for improvement, emphasizing the value they bring to the product/service and taking into account the impact of that change in all areas of the project (baseline).
Tips for a successful Requirements Elicitation
Below there is a list of tips that will help you find a set of necessary, complete, consistent, and unambiguous requirements.
- Role of the client: the success of the Requirements Elicitation phase depends on the availability and readiness of the client. It is necessary that the client understands the benefits of a good Requirements Elicitation. We must put an end to the poses: “The Requirements Elicitation is a loss of time. Starting to develop as soon as possible is better” (even if it means not having clear what we have to develop) or “With a session of Requirements Elicitation is enough, I have no time” (when the time and cost of implementing a change after will be higher). Customers must have an active role in the search and decomposition of their needs in requirements.
- Understand the current customer’s needs and future projection: find answers to the questions what is the reason/need of the requirement? What is your benefit? What are the goals? You need to analyze not only the current context of the client, but also their future goals and interests. This can impact, for example, on the solution’s design.
- Requirements Elicitation face to face: the best techniques involve face to face communications with the client. Why? First, it lets you create an atmosphere of greater trust with the customer, where feedback is encouraged. And second, it allows for a further dimension of analysis, consisting of the non-verbal language (gestures, looks) and paralingual language (tone of voice, emphasis), which enables more effective communication. For example, have you noticed that the client doubts before answering questions about a certain aspect of product? Maybe that’s a sign that the client is not completely sure of what he wants and you can help shape his/her expectations. I recommend keeping active meetings with the client or visiting him/her at his workplace, to know his/her day-to-day operations or flows involved in the solution. When this is not possible, you can use tools such as video conferencing that are useful to represent this type of approach.
- Interviewing the right people: a project can have thousands of stakeholders and the requirements elicitation time is finite. You cannot spend a year interviewing each stakeholder and finding out what their expectations are. The stakeholder’s level of participation in the requirements elicitation phase must be proportional to the stakeholder’s level of commitment, interest, and influence in the project.
- Level of detail: How far should the requirements elicitation continue? How deep should the seeking of requirements be? These questions arise naturally to all Functional Analysts. My recommendation is to stop at the point where WHAT (functionalities, quality requirements, safety, expected behavior) was clearly defined. HOW is the responsibility of the development team. At this point you must be careful because any excess detail could become a constraint on the solution’s design, limiting the creativity of the team.
- Maintain requirements traceability: it is important to track each requirement, recording its life cycle. This includes, for example, to know who requested the requirement, on what date, if it was approved or rejected, if it was modified, etc.
I hope these tips help you in the process of requirement elicitation and make your project a successful one.
Do not forget to post your comments in the section below. If you need any further information, do not hesitate to contact me at renata.lucione@intraway.com.
