Los requisitos intervienen al menos en cuatro aspectos importantes de los proyectos: definen el alcance, determinan los controles de calidad, establecen las condiciones de validación de lo ejecutado y justifican el grado de calidad obtenido.
La anterior entrada del blog ponía de manifiesto la importancia de gestionar los requisitos. Me propuse aclarar en qué consisten, cuáles son las fuentes que los generan, y la necesidad de gestionarlos a lo largo del proyecto o de la obra.
En el sector de la construcción, y principalmente en el de la ingeniería civil, los requisitos de tipo normativo son los más relevantes para finalizar exitosamente un proyecto. En consecuencia, a ellos se dedica fundamentalmente esta entrada.
Con tal motivo, trataré de exponer una metodología sencilla y contrastada que permite gestionar los requisitos de un modo sistemático, lo que introduce una gran fiabilidad para que el proyecto cumpla sus objetivos de coste, plazo y calidad.
Requisitos legales y expectativas
Los requisitos derivados de las expectativas, necesidades o deseos, ofrecen principalmente las claves de la mejora del grado de calidad de nuestro trabajo. En los de naturaleza normativa descubriremos la información necesaria para definir adecuadamente el alcance y garantizar que nuestras obras podrán ser validadas para su función final.
Si nuestro proyecto consiste en el desarrollo de un programa informático, el conocimiento de las necesidades del cliente es mucho más relevante que las cuestiones legales; por el contrario, en la ejecución de una obra civil, las restricciones legales priman sobre los deseos de los usuarios o del promotor. El trabajo de un arquitecto se sitúa en un punto intermedio, ya que las necesidades y gustos del cliente no se pueden satisfacer por el mero hecho de cumplir una serie de normas legales.
Para facilitar la exposición, la metodología que se expone se centrará en la gestión de requisitos de tipo normativo, pero podrá ser aplicable a otros de cualquier naturaleza.
La gestión convencional de requisitos normativos
Cualquier estándar de dirección de proyectos se basa en buenas prácticas de gestión. En el PMBOK, el trabajo de planificación de un proyecto u obra comienza con la identificación de interesados y continúa con la extracción de los requisitos, que se derivan de ellos. A partir de ahí se define lo qué hay que hacer (gestión del alcance), en qué plazo (gestión del cronograma), con qué calidad (gestión de la calidad), etc.
Podemos preguntarnos entonces cuánto se parece nuestra forma de gestionar los requisitos a estas recomendaciones basadas en infinidad de experiencias. También podríamos cuestionarnos sobre cómo compartimos los resultados de esta gestión con el personal y con las organizaciones que intervienen en el proyecto o la obra, y, por último, cómo comprobamos que se van a cumplir o que se hayan cumplido estos requisitos.
Sin embargo, creo que no me engaño mucho si afirmo que la gestión convencional de requisitos se suele reducir a generar un listado de la normativa aplicable al proyecto interminable y soporífero. En el mejor de los casos, pensamos que alguien se habrá preocupado de comprobar que las normas estén vigentes y organizadas por disciplinas… y poco más.
Ahora bien: ¿Cómo sabemos si cada responsable conoce los trámites que le corresponden y si es consciente de en que plazo deben estar resueltos? Efectivamente, esperar que todos los intervinientes en el proyecto o la obra lean motu proprio la normativa, y que la cumplan, es apelar exclusivamente al buen hacer de los miembros del equipo de proyecto. Esto es claramente insuficiente y arriesgado.
Además, no basta con cumplir una gran proporción de los requisitos. Muchas veces los problemas surgen por no disponer de una autorización que no se ha identificado o no se ha gestionado a tiempo. Se trata de cumplir el 100% de los requisitos para lo que se necesita una labor sistemática.
Propuesta metodológica: herramientas
Para llevar a cabo esta propuesta metodológica solo se necesitan dos herramientas, que son poco sofisticadas: las reuniones y un libro Excel.
Las reuniones para extraer los requisitos se celebrarán con miembros experimentados del equipo de proyecto u obra (dirección facultativa, asistencias técnicas, contratista y eventualmente subcontratistas y asesores).
En cuanto al manejo de la hoja Excel, se precisa un nivel de usuario medio – alto. Es interesante dominar funciones como BuscarV y ordenar tablas, emplear listas desplegables concatenadas, manejar filtros, etc. También sería recomendable saber trabajar con tablas dinámicas e incluso programar en Visual BASIC algunas macros para facilitar el trabajo.
Primer proceso: Recopilación de las fuentes de requisitos normativos
Esta parte de la metodología es quizá la más crítica, puesto que la maraña de competencias asignadas al aparato administrativo es cada vez más compleja y tupida. Muchas veces lo más complicado no es extraer los requisitos de una norma, si no saber que esa norma se debe aplicar. Por ejemplo, la ejecución de un sondeo debe tener autorización del servicio autonómico competente en actividades mineras, algo que no se sabe habitualmente.
Seguidamente, una vez determinados los organismos competentes u otras fuentes de requisitos, debiéramos elaborar un registro debidamente estructurado para su gestión. Para ello se propone emplear una de las hojas del libro Excel de gestión de requisitos en el que se podrán cubrir los campos reflejados en la siguiente tabla.
| CAMPO PARA REGISTRO DE NORMATIVA O DE DOCUMENTOS DE REQUISITOS | OBSERVACIONES |
| Nº FUENTE DE REQUISITOS | Es un número de orden que se utilizará para la gestión en el ámbito de Excel. |
| ÁREA DE GESTIÓN | Hace referencia a la disciplina o área de gestión. Por ejemplo Calidad, Medio ambiente y Prevención de riesgos. |
| NOMBRE DE LA FUENTE DE REQUISITOS | Es el nombre oficial completo de la normativa. En muchas ocasiones, muy extensa. |
| NOMBRE REDUCIDO DE LA FUENTE DE REQUISITOS | Es el nombre abreviado con el que nos referimos a la norma. Es muy útil ya que muchas leyes tienen nombres oficiales larguísimos. |
| CLAVE DEL DOCUMENTO | Abreviatura o acrónimo que se empleará en la codificación de los requisitos que se deriven de esta normativa o documento fuente de requisitos. |
| FECHA FUENTE REQUISITOS. | Fecha de la normativa o de creación del documento de requisitos. |
| FECHA ÚLTIMA REVISIÓN | Fecha de la revisión de la normativa |
| SITUACIÓN EXTRACCIÓN REQUISITOS | Campo para gestionar si los requisitos están extraídos o no. |
| LOCALIZACIÓN DE LA FUENTE DE REQUISITOS | Hipervínculo para la localización del documento original en el sistema de gestión documental de la organización. |
| COMENTARIOS | Campo para reflejar cualquier aclaración. |
En la siguiente imagen se muestra una vista parcial del registro de las fuentes de requisitos.
Segundo proceso: Extracción de los requisitos
Después de superar el escollo de conocer que normativa concreta u otras fuentes de requisitos, toca realizar la extracción de requisitos propiamente dicha. El objetivo es elaborar un listado de , adecuadamente codificado y estructurado, con una descripción sencilla de los requisitos y con la posibilidad de comprender el contexto de donde se ha extraído.
Para que el registro de requisitos sea fiable y se obtenga de un modo eficiente debemos instruir y alinear adecuadamente a los responsables de llevarlo a cabo. Se trata de una información muy relevante y debemos estar seguros de que se realiza correctamente. El registro obtenido va a emplearse a lo largo de todo el proyecto o la obra, por lo que se le debe prestar mucha atención a su calidad.
En la siguiente tabla se aprecia el aspecto del registro que se propone. El listado de requisitos ocupa una de las hojas Excel del libro Excel. En la parte superior se observan los botones que permiten activar las diferentes macros para gestionar más eficientemente la información del libro Excel.
En la siguiente tabla se detallan los diferentes campos cubiertos para el requisito “PRL-1-Integrar la PRL en el SIG mediante un Plan de PRL“.
| Valor para el requisito del ejemplo | COMENTARIOS CAMPO | Valor para el requisito del ejemplo |
| nº Fuente de requisitos | Es el número de orden dado a la fuente de requisitos. | 1 |
| nº requisito de fuente | Establece el orden y cantidad de requisitos obtenidos de una misma fuente. | 1 |
| Documento legal o normativo | Es la denominación oficial del documento o norma, sin realizar ninguna simplificación. | Ley 31/1995, de 8 de noviembre, de Prevención de Riesgos Laborales. |
| Denom Reducida del Documento o norma Legal | Nombre más reducido por el que se hace referencia habitual a la norma o documento. En este caso se mantiene el mismo. | Ley 31/95 de Prevención de Riesgos Laborales |
| Requisito identificado | Debe ser una oración sencilla, clara y completa con la que se comprenda en qué consiste el requisito. | “Integrar la PRL en el SIG mediante un Plan de PRL” |
| Texto origen requisito | Es un copia-pega textual de la parte del texto del que se deriva el requisito. Incluirá alguna referencia que permita localizarlo con facilidad en el texto. Podrán eliminarse las partes que no aportan sustituyéndolas mediante corchetes ([…]). | “Artículo 16. Plan de prevención de riesgos laborales, evaluación de los riesgos y planificación de la actividad preventiva. 1. La prevención de riesgos laborales deberá integrarse en el sistema general de gestión de la empresa, tanto en el conjunto de sus actividades como en todos los niveles jerárquicos de ésta, a través de la implantación y aplicación de un plan de prevención de riesgos laborales a que se refiere el párrafo siguiente.” |
| Clave del documento. | Es la abreviatura o acrónimo de la norma o fuente de requisitos. | PRL |
| Código del Requisito | Es la concatenación de la clave del documento con el número de requisito de ese documento. | PRL-1 |
| Área de gestión | Disciplina a la que aplica. | PrevRiesgLab |
| Requisito codificado | Denominación completa del requisito obtenido mediante la concatenación de la clave y el nombre. | PRL-1-Integrar la PRL en el SIG mediante un Plan de PRL |
| Proceso de aplicación | Proceso del sistema de gestión al que se aplica. | PA-03 Gest Seg y salud |
| Subprocesos | PrevRiesgLab | |
| Responsable | Responsable de cumplimentar el requisito. | Responsable de calidad |
| Situación | En este ejemplo aun no está integrado la PRL en el sistema de gestión. | Pendiente |
Tercer proceso: El control de lo planificado
No quisiera finalizar esta exposición sin hacer un alegato a la importancia de los procesos de control.
Es muy frecuente dedicar grandes esfuerzos en desarrollar planificaciones iniciales en cualquiera de los ámbito de gestión, pero este impulso inicial se suele perder a lo largo del proyecto. A lo sumo se vuelve a planificar en otras ocasiones, pero no se aplican procesos específicos de control.
El esfuerzo planificador se desaprovecha cuando no se lleva a cabo un control de lo planificado. En el caso de los requisitos, el control exige incluir la revisión de su estado y la incorporación de nuevos en las reuniones de seguimiento de las obras. El control de requisitos debe ser un apartado más del orden del día de las reuniones de seguimiento. Los filtros y las tablas dinámicas serán aliados muy importantes para realizar este trabajo de un modo muy práctico y eficiente.
