1. La experiencia
Hace unas semanas entreviste varias y varios colegas involucrados en la Dirección de proyectos de cooperación sobre sus experiencias positivas y negativas. Fueron muchas ideas recogidas y los aprendizajes logrados.
Hoy quiero referirme analizar el tema de los requisitos del proyecto. Una colega me indicaba que: “la identificación de requisitos del alcance del proyecto es una tarea de mucha importancia, pero lamentablemente, por distintas razones, no se dedica el tiempo suficiente y muchas veces queda incompleta. Como consecuencias se generan dificultades y conflictos en la implementación del proyecto. Para ilustrar mejor el tema me apoyaré en un ejemplo: fue uno sobre generación de empleo. Se planeó y se firmó un convenio con el financiador, quien deseaba una ejecución rápida y eficiente. Previa a la firma se hizo una rápida evaluación de requisitos de los entregables y del proceso administrativo. Al momento de rendir los informes y esperar los pagos acordados, aparecieran requerimientos no definidos claramente en el comienzo: que el empleo debería ser solo y exclusivamente con el quintil más pobre y no con los quintiles subsiguientes, que la documentación sobre evidencias, debería tener una copia del contrato de trabajo de la empresa en original y expedida por el empleador, que cada folio debería tener una constancia del tiempo trabajado.
Algunos de los argumentos que brindamos a los financiadores fueron: a) Se detectó, al momento de la ejecución, que los quintiles 3 y 4 tenían mayor motivación y posibilidad para concretar un empleo que los más pobres (quintil 5). Éstos no estaban motivados para formalizar un empleo, pues reciben un subsidio del Estado sin mayores tramites y costos, y cuyo valor no es muy lejano del salario mínimo que recibirían en una empresa. Por esto, se buscó ampliar el grupo objetivo al quintil 4. b) En la carpeta de cada empleado no se brindan originales de los contratos de trabajo, debido a que las políticas internas de las empresas impiden obtener la información y muchos empleados no guardan copias de su contrato o no desean entregarlas. Los argumentos no fueron aceptados, hecho que generó conflictos, re-trabajos, renegociaciones y, desde luego, costos adicionales significativos para nosotros como ejecutores”.
¿Qué falló en este caso? Faltó mayor atención en la identificación de requisitos y los criterios para hacer cambio y renegociar, en caso necesario.
2. ¿Qué nos dice la teoría y las lecciones aprendidas de otros proyectos sobre la gestión de requisitos?
2.1 ¿Qué se entiende por requisitos?
Los requisitos o requerimientos son las características, las expectativas los aspectos esperados o las capacidades que debe cumplir el producto o servicio que generará el proyecto. Incluye además las cualidades que debe tener el proyecto para cumplir los requisitos del producto. Por esto se distingue entre requisitos funcionales y no funcionales. Los primeros definen qué debe cumplir el producto o servicio y los segundos cómo debe ser el proyecto para que el producto cumpla el propósito.
Tomemos el caso de un proyecto que genera estufas mejoradas para las poblaciones pobres de una región. Los requisitos funcionales serían, por ejemplo, el rendimiento de la estufa (con menor cantidad de leña u otro combustible local, las estufas generan más calor), la extracción de humo y el menor tiempo de cocción de los alimentos. Los no funcionales serían: la facilidad de uso, la seguridad, la disponibilidad (sea vía el Estado o vía el mercado) la integridad (responden a un estándar), la escalabilidad, la facilidad de trasportarla de un lugar a otro, los elementos regulatorios (subsidios, normas de uso, entre otros). No siempre es fácil hacer la clasificación. A veces hay dudas dónde colocar el requisito. Esto no es tan grave, siempre se discutirá en el grupo del proyecto y se llegará a un consenso. Lo fundamental es haberlos identificado en forma oportuna y completa, y haberlos definido en forma clara, concisa y concreta.
De acuerdo a un estudio de costos en proyectos realizado Cost & Economic Analysis Branch, National Aeronautics and Space Administration headquarters (NASA), los proyectos que gastaron menos del 5% de su costo total en gestión de requisitos experimentaron de 80 a 200% de sobrecosto, mientras que los que gastaron entre 8% y 14% en este tema, experimentaron un 60% de sobrecosto máximo. (Citado por González, 2016)). La importancia fundamental de identificar los requisitos es que ayuda a definir el alcance real del proyecto.
2.2 ¿Cómo se identifican, clasifican y seleccionan los requisitos?
* La identificación de los requisitos o requerimientos demanda la obtención de información precisa. Se tienen varios tópicos a clarificar: a) Describir claramente el o los productos y/o servicios que el proyecto debe generar: calidad, elementos que lo componen y sus interrelaciones, pasos a dar en la producción, b) ¿Qué expectativas tienen los clientes?, ¿Es un solo segmento o existen varios segmentos de clientes? c) ¿Qué expectativas y objetivos tienen los diferentes interesados en el proyecto (stakeholders)? d) ¿Qué normas y qué estándares existen para el producto o servicio y para el proceso de producción (pasos)? e) ¿A quién, qué, y cómo se debe informar sobre los requerimientos funcionales y no funcionales
* El proceso de obtener los requisitos tiene varios pasos: 1) identificar de qué o de quien voy a obtener la información requerida. Se puede obtener información del acta de constitución del proyecto, del archivo de lecciones aprendidas de proyectos anteriores similares, de la observación y análisis de productos o servicios semejantes o análogos que tiene la competencia; 2) de la literatura (información secundaria) existente sobre éstos y 3) información primaria de los interesados en el proyecto (significa qué es necesario conocer todos los involucrados y establecer cómo obtener la información de ellos).
* No hay que olvidar que la información secundaria es la más económica y que se debe siempre iniciar por ésta. La información debe ser vertida en matrices diseñadas previamente, para ir resumiendo e identificando los requisitos.
* La obtención de requisitos vía información primaria puede hacerse mediante varios métodos: entrevistas con informantes clave, observación participante o no participante, grupos focales, y encuestas. Hay que diseñar el método a usar y preparar los formatos en los que se recogerán los datos, para analizarlos y definir la lista de requisitos.
2.3 ¿Quién y cuándo hacer la identificación de requisitos?
* La identificación, selección, organización y priorización de los requisitos es una tarea del Director o Directora del proyecto. Las y los colaboradores del proyecto deben estar involucrados en esta tarea. Se debe realizar en la fase de planificación del proyecto, pues son elemento básico para definir el alcance. Cuando el proyecto se divide en fases cortas, se deben identificar y priorizar los requisitos para cada una de ellas. Los requisitos deben ser validados y verificados continuamente.
* La Dirección debe tener en cuenta algunos criterios para priorizar y asegurarse que los requisitos definidos tanto del producto o servicios como del proyecto en general responden a las expectativas de clientes y stakeholders en general. Algunos son: formulaciones concretas y prácticas, requisitos medibles y sin incoherencias entre ellos, aprobados y listados en la matriz de trazabilidad y comunicados oportunamente, para definir el alcance del proyecto.
2.4 ¿Cómo y cuándo se deben decidir los cambios a que haya lugar?
* La definición de requisitos es una tarea dinámica e iterativa en la vida del proyecto. Esto significa que la dirección debe darle un seguimiento y que dicho seguimiento debe ser documentado. En la experiencia vimos que ésta fue una de las dificultades.
Para hacer el seguimiento los estándares de dirección muestran que se deben especificar desde el inicio la forma de llevar un control integrado de cambios, que consiste en especificar cómo se trataran las solicitudes de cambio que se presenten: aprobación, gestión, documentación, arreglo de la línea de base del proyecto y comunicación de cada solicitud.
* Para llevar un historial de los requisitos (definición inicial y cambios ocurridos durante la vida del proyecto) se recomienda utilizar la denominada Matriz de trazabilidad. Esta matriz permite describir el requisito, establecer el cumplimiento relacionarlos con los entregables específicos acordados y con los objetivos del proyecto. Ayuda a la dirección a evaluar si los requisitos fueron aprobados, si se cumplieron y qué efecto tuvieron. Formatos de la matriz son fácilmente adquiribles en el PMBOK y en muchos artículos sobre dirección de proyectos.
3. A manera de conclusión
El esfuerzo que realice la dirección en la identificación, categorización, priorización y documentación de los requisitos del proyecto a su cargo, siempre resultaran en buenos beneficios y mayores probabilidades de éxito. Se piensa que es mucho trabajo realizar una tarea minuciosa, cuando hay altas presiones por iniciar la ejecución. Sin embargo, resistir la presión y asegurar la tarea evitará muchos sinsabores. No hay que olvidar que los requisitos se pueden complementar y cambiar durante la vida del proyecto. Lo esencial es definir cómo se hacen los cambios y asegurar que las reglas están respaldadas en el contrato o convenio.
5. Bibliografía básica utilizada
- Aceves, L. C. 2008. Definición de requerimientos y funcionalidades. Recuperado el 26.10.2.18 de: https://es.slideshare.net/laceves/definicin-de-requerimientos-y-funcionalidades”>https://es.slideshare.net/laceves/definicin-de-requerimientos-y-funcionalidades
- Google Sites. S.f. Metodología Gestión de Requerimientos. Recuperado el 27.10.208
de: https://sites.google.com/site/metodologiareq/home - González, M. 2016. Gestión de requisitos en proyectos. Recuperado el 26.10.2018 de: Avanza/Project success: https://www.avanzaproyectos.com/2015/02/13/gestion-de-requisitos-en-proyectos/
- PMI. 2017. La guía de los fundamentos para la dirección de proyectos (Guía del PMBOK). Project Management Institute, PMI. Newton Square, Pennsylvania, USA.
- PMOinformatica.com La oficina de proyectos de informática. 2017. Varias páginas sobre requerimientos de proyectos: Ej.: http://www.pmoinformatica.com/2017/02/requerimientos-funcionales-ejemplos.html