MANUAL GESTION DE PROYECTOS

MANUAL GESTIÓN DE PROYECTOS

Esta “escenificación” sirve para trasladar un mensaje claro a los interesados: todo está terminado y ya no tienen derecho a solicitar más cambios.

Con el fin de gestionar el proyecto para que su cierre sea efectivo, desde el comienzo de la gestión hay que saber qué quieren los interesados, o lo que es lo mismo: sus requisitos. Especialmente importantes son los requisitos de quienes deben aceptar el producto del proyecto, es decir, aquellos que van a ejercer el papel de clientes del proyecto, u organización solicitante Los requisitos tienen una gestión complicada porque suelen cambiar muy a menudo. Muchas veces los clientes no saben lo que quieren (siempre saben lo que no quieren: hasta que no tienen una entrega no suelen pronunciarse). Cada vez es menos frecuente que los clientes nos aprueben formalmente una línea base de requisitos, pero no por ello hay que desistir en este objetivo de gestión. ¿Qué es lo peor que puede ocurrir en un proyecto? Que los requisitos cambien todos los días (esto se denomina corrupción del alcance o scope creep). ¿Cómo podemos mitigar este riesgo? Escribiendo una lista de requisitos, documentada de tal manera que sirva para especificar el producto y para consensuar la definición de trabajo terminado (definition of done) o lo que es lo mismo: la condición para cerrar el proyecto. Si todo está terminado en las condiciones pactadas, entonces se puede cerrar el proyecto. Gestionar el alcance en proyectos es diferente que gestionar el alcance en operaciones. Pensemos en el caso práctico desarrollado en el anexo, el proyecto de traducir un libro. Un traductor que se dedique habitualmente a traducir textos, o a corregirlos, no está ejecutando proyectos, sino que su actividad es repetitiva. A pesar de que no son proyectos, estos trabajos de traducción tienen requisitos de producto de tipo funcional (idioma destino, textos a traducir, gráficos a traducir, etc.), y requisitos de producto de tipo no funcional (adaptación al estilo de los potenciales lectores, estilos de redacción, formatos de texto, etc.). También tienen requisitos de gestión (plazos de entrega, proceso de revisiones, material de marketing, etc.). Cuando la traducción es un proyecto como en nuestro caso práctico, sigue siendo muy importante cumplir los objetivos de producto, pero quizá sea más importante “envolver” el resultado a obtener dentro de un esfuerzo organizado, dirigido a cumplir los objetivos del proyecto: fecha de entrega, voluntariado del PMI, consenso de profesionales, etc. Si la editorial hubiera encargado que cada voluntario tradujese ciertos capítulos, no sería un proyecto. Sin embargo, la editorial encargó una traducción completa y dio libertad de gestión. Los requisitos de producto de la traducción siguen estando allí, pero hay que “envolver” esos objetivos en una entidad de gestión mayor, llamada proyecto. Como se puede observar en la figura, el alcance de un proyecto incluye elementos del producto del proyecto (producto, servicio, o resultado final) y de proyecto, o proceso (cómo hay que trabajar para conseguir que el producto y el proyecto cumplan los objetivos).

33

European Open Business School