Los Proyectos nacen como un instrumento fundamental que utilizan las empresas para dar respuestas y construir las soluciones que conlleven a la satisfacción de las necesidades del negocio y al logro de los objetivos. Es por ello que un proyecto debe estar asociado a un caso de negocio que se definió para satisfacer una necesidad, contribuir al logro de un objetivo del negocio, eliminar una amenaza, aprovechar una oportunidad, convertir en fortaleza una debilidad, mejorar sus competencias, expandir los mercados de sus productos y servicios, y ganarse la preferencia de sus clientes lo que al final se traduce en mayores ventas y ganancias.
Sin embargo, cuántas veces hemos escuchado y leído de las frustraciones de organizaciones que han invertido importantes recursos financieros ejecutando proyectos que fueron desechados a la basura o han tenido que gastar muchos recursos en re-hacer, adecuar y re-trabajar en adaptar productos y entregables de dichos proyectos porque no satisfacen la necesidad del negocio y las expectativas de los Usuarios para la cual fueron formulados.
Muchos de estos proyectos han sido destinados al fracaso desde un principio porque no han dedicado el tiempo suficiente en la definición y validación de los requerimientos, en la selección de los Stakeholders, y en lograr el compromiso e involucramiento de los SME (Subject-Matter Expert por sus siglas en Ingles) los cuales constituyen piezas fundamentales durante el levantamiento, definición y validación de los requerimientos.
Recordemos que los SME son trabajadores con un nivel alto de experticia, conocimiento y dominio de los trabajos, procesos y productos de sus organizaciones. Asimismo, los Stakeholders son definidos como las personas, usuarios u organizaciones que tienen algún interés en el desarrollo del proyecto.
Corregir deficiencias y ambigüedades de los requerimientos una vez iniciada la fase de ejecución del proyecto es sumamente costoso ya que involucra re-trabajo, re-diseño de las soluciones, productos y entregables; actualización del Plan y de todos los documentos del proyecto que conllevan al consumo de recursos financieros, humanos y tiempo no planificados ni contemplados en el presupuesto.
Mayor es el impacto en proyectos orientados bajo la metodología Waterfall porque la Metodología asume que los Requerimientos están claramente definidos desde el principio y se mantienen estables hasta la competición del proyecto, y una vez iniciado dicho proyecto los cambios son controlados, reducidos y evitados en lo posible.
Un Requerimiento puede ser ambiguo o estar mal definido por muchas razones:
- Identificación incorrecta de los Stakeholders, es decir, la lista estuvo incompleta, no son todos los que están, ni están todos los que son.
- El nivel de competencia de los Stakeholders, conocimiento, dominio de los procesos de negocio de sus organizaciones no es el adecuado.
- Falta de alineación y compromiso de los Stakeholders con el proyecto porque perciben que el beneficio para sus propios procesos u organización es poco o casi nada.
- Poco nivel de influencia sobre la organización para lograr el compromiso de los miembros de la organización a la cual pertenecen.
- Inexperiencia del Analista de Negocio, y del Analista de Requerimientos.
- Nombramiento tardío del Gerente de Proyectos, el cual debe ser nombrado y autorizado en la Carta del Proyecto durante el proceso de Iniciación, de tal manera que pueda conjuntamente con el Analista de Negocio (en los casos donde exista) y del Analista de Requerimientos revisar los documentos del Caso de Negocio, Análisis de factibilidad, y definición de la solución realizados durante la fase de justificación del proyecto, y que servirán de insumos durante la Planificación.
Sin embargo, en todos los casos ya mencionados, la responsabilidad recae sobre el Gerente de Proyecto el cual debe prestar especial atención para asegurarse que los requerimientos sean precisos, que el equipo de proyecto tenga una única interpretación de los requerimientos, que hayan sido validados por los SME, Usuarios y Stakeholders, y hayan sido cruzados para identificar algún conflicto entre ellos, y de ser así clarificarlo con los otros Stakeholders y SME para solucionar el conflicto.
Además, el Gerente de Proyecto debe asegurarse que en la solución, productos y entregables a ser producidos por el proyecto se puedan identificar cada requerimiento. Es decir, que se exista el mecanismo que permita realizar el “tracking” o seguimiento de cada requerimiento y del producto o entregable que lo contenga.
En la metodología Agile o Scrum, cambiar o re-definir un requerimiento (User’s Stories) es más sencillo porque asume que los requerimientos pueden cambiar, no son estáticos, no requiere que estén bien definidos desde el principio, los ciclos de los Sprint son más cortos (de 2 a 4 semanas), pocos requerimientos por cada Sprint Backlog (todas las historias que pueden ser completamente implementadas hasta el final del Sprint) y un requerimiento ambiguo puede ser diferido para un posterior Sprint durante la reunión de planificación del Sprint (Sprint Planning Meeting).
Sin embargo, en ambas metodologías, sigue siendo fundamental el papel que desempeñan los Stakeholders y los SME, y una incorrecta identificación de ellos y su poco compromiso puede afectar el desempeño de los proyectos independiente de la metodología usada, porque aun cuando pareciera más sencillo en la metodología Agile o Scrum solucionar ambigüedades en los requerimientos, van a depender del nivel de compromiso de los Stakeholders y SME para proveer el tiempo requerido, la información y conocimiento del negocio necesario para definir y clarificar los requerimientos o historias; y del nivel de influencia del Product owner (Gerente de Proyecto) sobre la organización y sobre los Stakeholders.
