Requisitos del proyecto: cómo recopilarlos y analizarlos

Los requisitos del proyecto son un aspecto clave para completar el proyecto a tiempo y sin exceder los límites del presupuesto.

Esta es una de las habilidades esenciales de un gestor de proyectos, a menudo subestimada, que consiste en la recopilación y el análisis de estos aspectos del plan.

Es muy importante comprender claramente los requisitos de cualquier proyecto que estés a punto de emprender.

Demasiados proyectos han fracasado debido a la falta de requisitos bien definidos.

Como afirma el Project Management Institute

El 47 % de los proyectos fracasaron debido a una mala gestión de los requisitos.

No existen dos proyectos idénticos: cada proyecto tiene su propio conjunto de requisitos y es responsabilidad del gerente de proyecto identificarlos correctamente.

Cuanto más complejo es el proyecto, mayor es la necesidad de definir los requisitos para encontrar procesos específicos para cada parte del proyecto.

¿Cuáles son los requisitos del proyecto?

Las partes interesadas escuchan el término «requisitos», pero cada uno entiende su significado de manera diferente, dependiendo de los objetivos.

Por lo tanto, antes de poder examinar cualquier cosa, es esencial tener una definición operativa unívoca.

Parte de la confusión relacionada con los requisitos radica en el hecho de que existen varios tipos. Por lo tanto, intentaremos adherirnos a la clasificación realizada por el PMBOK (enlace al artículo PMBOK)

El PMBOK, desde la sexta edición en adelante, clasifica los requisitos del proyecto de la siguiente manera:

• Corporativos: describen la razón del proyecto;
• De las partes interesadas: describen las necesidades de una parte interesada o grupo de partes interesadas;
• Solución: describen las características, funciones y atributos del producto, servicio o resultado que satisface las necesidades corporativas y de las partes interesadas;
• Funcionales: describen el comportamiento del producto o servicio;
• No funcionales: describen las condiciones ambientales o las cualidades necesarias para que el producto o servicio sea eficaz;
• De transición: describen las capacidades temporales necesarias para pasar del estado actual al estado deseado en el futuro;
• Del proyecto: describen las acciones, los procesos u otras condiciones que el proyecto debe cumplir;
• De calidad: describen cualquier condición o criterio que valida la finalización exitosa de un resultado del proyecto o el cumplimiento de otros requisitos del proyecto.

Pero, ¿por qué son tan importantes los requisitos para un proyecto?

Cuando los requisitos no están claros, los proyectos corren riesgos; es posible que no produzcan el resultado deseado y necesario.

Como mínimo, los requisitos faltantes implican retrabajo.

En resumen, la falta de requisitos del proyecto o su mala definición produce impactos negativos en el programa y en el presupuesto.

Obviamente, los clientes, así como los miembros del equipo, no estarán contentos con estas deficiencias.

Examinamos los pasos esenciales para llegar a una correcta identificación y procesamiento de los requisitos del proyecto.

Recopilar los requisitos del proyecto

Un gerente de proyecto no puede esperar que los requisitos del proyecto le sean entregados en bandeja de plata.

Las partes interesadas pueden no saber exactamente lo que quieren y, por lo tanto, deben ser ayudadas a formular sus requisitos.

Un buen gerente de proyecto sabe cómo recopilar los requisitos. En caso de que no lo sepa, tendrá que pedir ayuda a quienes poseen las habilidades necesarias.

Las herramientas para recopilar los requisitos

Aquí hay algunas herramientas y técnicas que pueden ser útiles para el proceso de recopilación de requisitos:

• Lluvia de ideas: también conocida como pensamiento grupal o creatividad grupal. Por lo general, se reúne a personas con diferentes roles y funciones para esto. Esta técnica es muy útil cuando no tienes necesidades fijas y quieres intentar explorar nuevos requisitos y nuevos horizontes.
• Entrevistas / cuestionarios: esta técnica se suele utilizar en el caso de grupos grandes. Tener un gran número de partes interesadas no permite organizar una entrevista individual. Ten cuidado, sin embargo, de hacer las preguntas correctas y pertinentes para una recopilación correcta y real de las necesidades de las partes interesadas.
• Entrevistas: una herramienta que involucra personalmente a las partes interesadas para comprender sus necesidades. Las entrevistas pueden facilitarse mediante reuniones personales o llamadas telefónicas.
• Benchmarking: en esta técnica, se realiza una comparación entre las prácticas existentes y las mejores prácticas del mercado. Con el análisis de brechas con respecto a estos ejemplos de excelencia, se pueden determinar los posibles requisitos del proyecto.
• Diagrama de contexto: estos diagramas representan una visualización pictórica de varias interacciones entre los usuarios y diferentes sistemas. Por lo tanto, describen los pasos necesarios para obtener los resultados y pueden ser adecuados para identificar los requisitos.

En cada uno de estos casos es importante contar con un software de gestión de proyectos que permita, en la elaboración del proyecto, integrar estos requisitos como parte fundamental del propio proyecto.

Análisis de requisitos

La palabra «analizar» significa descomponer o examinar en detalle la constitución o estructura de algo.

Si la situación lo permite, una de las formas más poderosas de analizar es crear prototipos o diagramas.

Cuando los usuarios pueden ver y/o tocar las cosas, es más fácil ver qué les gusta y qué no. Un prototipo o un diagrama es más tangible que los datos simples.

Además, en algunos casos, se examina la prioridad de cada requisito durante el análisis. Para hacerlo, debes hacerte algunas preguntas. Aquí hay algunos ejemplos:

1. ¿Qué características y funciones ofrecen el máximo beneficio para el proyecto?
2. ¿Cuáles pueden causar el mayor riesgo?

Una vez analizados, los requisitos se documentan y formalizan en el documento del proyecto.

Lo que el gerente de proyecto debe hacer en general es mantener a su equipo y cliente enfocados en definir claramente los objetivos del proyecto y mapear requisitos válidos, detallados y comprensibles.

Todo esto, con el fin de crear una solución final que proporcione lo que el cliente realmente desea.

Los criterios para un requisito del proyecto

En general, un buen requisito debe cumplir cuatro criterios básicos:

1. Un buen requisito debe satisfacer una necesidad específica
2. Un buen requisito es verificable
3. Un buen requisito es alcanzable
4. Un buen requisito es comprensible para todas las partes interesadas

Un buen requisito debe ser comprensible para todos los involucrados en el proyecto. Otro consejo es formular los requisitos en lenguaje afirmativo siempre que sea posible.

En conclusión, podemos decir que un conocimiento profundo de cómo diseñar, modificar y adaptar los procesos de requisitos es la clave para completar con éxito un proyecto.

El control del proyecto eficaz, una clara trazabilidad de los requisitos y una visión de alto nivel de las necesidades del cliente son elementos clave para garantizar que se alcancen los objetivos.

Un equipo de proyecto bien estructurado y organizado podrá enfrentar cada desafío y adaptarse a cualquier cambio con una gestión eficaz de los recursos y el tiempo.

Un buen requisito debe satisfacer una necesidad específica

Un requisito es básicamente una declaración de algo que alguien necesita.

Ese algo es un producto o una solución que presta un servicio o realiza una función.

Aunque sea verificable, alcanzable y esté bien declarado, un requisito que no sea necesario para la solución final no es realmente un buen requisito.

Por supuesto, la definición de la necesidad dependerá del contexto y las circunstancias, y deberá ser profundizada por el equipo y el cliente en cada situación específica.

Un buen requisito es verificable

Un requisito debe establecer algo que pueda verificarse mediante cuantificación, inspección, análisis o pruebas.

También es importante determinar los criterios específicos de aceptación, lo que garantizará consecuentemente requisitos verificables.

Un buen requisito es alcanzable

El requisito debe estar dentro del presupuesto y debe ser técnicamente viable.

Es importante no escribir requisitos para cosas que no se pueden construir o que no están razonablemente dentro del presupuesto o del cronograma del proyecto.

No siempre es fácil determinar esto y un gerente de proyecto puede no tener la experiencia para juzgar si un requisito es técnicamente viable.

En este caso, es necesario asegurarse de incluir a los miembros del equipo de desarrollo en el proceso de revisión para prever problemas técnicos.

Puede ser necesario realizar una investigación para determinar la viabilidad de un requisito antes de agregarlo a la línea base del proyecto.

Un buen requisito es comprensible para todas las partes interesadas

Un buen requisito es comprensible para todos los sujetos involucrados en el proyecto. Expresa una sola idea, es conciso y está escrito en oraciones cortas y simples con terminología coherente.

De esta manera, a medida que avanzas en las fases de diseño y desarrollo del proyecto, el requisito no cambiará de significado y siempre permanecerá claro para todos.

Otro consejo es formular los requisitos con lenguaje afirmativo siempre que sea posible.

Por ejemplo, es más fácil desarrollar y probar un producto que hace algo específico que uno que no hace algo específico.

En conclusión, podemos decir que una comprensión profunda de cómo diseñar, modificar y adaptar los procesos de requisitos es la clave para una finalización exitosa del proyecto.

Un control del proyecto efectivo, una clara trazabilidad de los requisitos y una visión de alto nivel de las necesidades del cliente son elementos clave para garantizar que se alcancen los objetivos.

Para optimizar la gestión de requisitos y mejorar la eficacia del proyecto, herramientas de gestión como Twproject pueden proporcionar un apoyo crucial para la planificación, el monitoreo y el control de todo el ciclo de vida del proyecto.