Projects are born as a fundamental instrument used by companies to provide answers and build solutions that lead to the satisfaction of business needs and the achievement of objectives. That is why a project must be associated with a business case that was defined to satisfy a need, contribute to the achievement of a business objective, eliminate a threat, take advantage of an opportunity, turn a weakness into strength, improve skills, expand markets for your products and services, and gain the preference of your customers which ultimately translates into higher sales and profits.
However, how many times have we heard and read about the frustrations of organizations that have invested significant financial resources executing projects that were discarded or have had to spend many resources on re-doing, adapting and re-working on adapting products and deliverables of said projects because they do not satisfy the business need and the expectations of the Users for which they were formulated.
Many of these projects have been doomed from the beginning because they have not spent enough time in defining and validating the requirements, in selecting Stakeholders, and in achieving the commitment and involvement of SMEs (Subject-Matter Expert for its acronym in English) which constitute fundamental pieces during the survey, definition and validation of the requirements.
Let us remember that SMEs are workers with a high level of expertise, knowledge and mastery of the jobs, processes and products of their organizations. Likewise, Stakeholders are defined as the people, users or organizations that have an interest in the development of the project.
Correcting deficiencies and ambiguities of the requirements once the execution phase of the project has started is extremely expensive since it involves rework, re-design of solutions, products and deliverables; Updating of the Plan and all project documents that lead to the consumption of financial, human and time resources not planned or contemplated in the budget.
The impact is greater in projects oriented under the Waterfall methodology because the Methodology assumes that the Requirements are clearly defined from the beginning and remain stable until the project competition, and once the project starts, changes are controlled, reduced and avoided as far as possible. possible.
A Requirement can be ambiguous or poorly defined for many reasons:
- Incorrect identification of the Stakeholders, that is, the list was incomplete, they are not all that they are, nor are they all The level of competence of the Stakeholders, knowledge, mastery of the business processes of their organizations is not the suitable. Lack of alignment and commitment of the Stakeholders with the project because they perceive that the benefit for their own processes or organization is little or almost nothing. Little level of influence over the organization to achieve the commitment of the members of the organization to which they belong. Inexperience of the Business Analyst, and the Requirements Analyst. Late Appointment of Project Manager, which must be named and authorized in the Project Charter during the Initiation process, in such a way that it can jointly with the Business Analyst (in cases where it exists) and the Requirements Analyst review the documents of the Business Case, Feasibility analysis and definition of the solution carried out during the justification phase of the project, and which will serve as inputs during Planning.
However, in all the cases already mentioned, the responsibility falls on the Project Manager, who must pay special attention to ensure that the requirements are accurate, that the project team has a single interpretation of the requirements, which have been validated by SMEs, Users and Stakeholders, and have been crossed to identify any conflict between them, and if so, clarify it with the other Stakeholders and SME to solve the conflict.
In addition, the Project Manager must ensure that each requirement can be identified in the solution, products and deliverables to be produced by the project. That is, there is a mechanism that allows the "tracking" or monitoring of each requirement and the product or deliverable that contains it.
In Agile or Scrum methodology, changing or redefining a requirement (User's Stories) is easier because it assumes that the requirements can change, they are not static, it does not require that they be well defined from the beginning, the Sprint cycles are more short (2 to 4 weeks), few requirements for each Sprint Backlog (all stories that can be fully implemented until the end of the Sprint) and an ambiguous requirement can be deferred for a subsequent Sprint during the Sprint planning meeting (Sprint Planning Meeting).
However, in both methodologies, the role played by Stakeholders and SMEs is still fundamental, and an incorrect identification of them and their low commitment can affect the performance of the projects regardless of the methodology used, because even when it seems simpler in The Agile or Scrum methodology to solve ambiguities in the requirements, will depend on the level of commitment of the Stakeholders and SME to provide the required time, information and business knowledge necessary to define and clarify the requirements or stories; and the level of influence of the Product owner (Project Manager) on the organization and on the Stakeholders.
