MA ST E R E N I NG E NI E RÍ A D E SOF TW A R E UNIVERSIDAD POLITÉCNICA DE CATALUNYA PROYECTO FINAL DE MÁSTER – MRF FRAMEWORK Informe Final del Proyecto Instrucciones Versión 1.0 ● 30 SEP 2008 Máster en Ingeniería de Software Proyecto Final de Máster – MRF Framework INSTRUCCIONES INFORME FINAL DEL PROYECTO Versión 1.0 | 30-SEP -2008 Tabla de Contenidos Introducción ............................................................................................................1 Uso del Informe de Cierre de Proyecto ..................................................................1 Sección 1 Información General ...........................................................................2 Sección 2 Lista de Verificación de Aceptación Final ...........................................3 Sección 3 Lista de Verificación de los Artefactos del Proyecto ...........................3 Sección 4 Recursos .............................................................................................4 Sección 5 Lecciones Aprendidas .........................................................................4 Sección 6 Planes Post-Implantación ...................................................................4 Sección 7 No Conformidades Abiertas ................................................................5 PMC-Instrucciones-10IFP-1.0 Página i Máster en Ingeniería de Software Proyecto Final de Máster – MRF Framework INSTRUCCIONES INFORME FINAL DEL PROYECTO Versión 1.0 | 30-SEP -2008 Introducción Muchos proyectos TIC tienen un enfoque limitado en ejecutar un cierre formal y estructurado del proyecto. Los GPIs y equipos de proyecto muchas veces subestiman el impacto y la utilidad de los datos históricos para la organización. En muchos casos, los artefactos entregables no son archivados consistentemente impidiendo un mejoramiento continuo y la promoción de la reutilización. El informe de cierre del proyecto se incluye como parte del framework para proveer un método consistente de cierre formal del proyecto. Una vez concluida la implementación del proyecto, la aceptación final se lleva a cabo en la fase de cierre. Los representantes de los GPIs tienen la oportunidad de establecer si las metas de negocio y objetivos del proyecto se han satisfecho antes de hacer el cierre de proyecto. El proyecto debe terminar formalmente delineando claramente el cierre antes de que comiencen las actividades post-implantación. Estableciendo planes para evaluación posterior al proyecto, tales como revisiones de implantación posteriores. Diferentes aspectos del proyecto (Ej: administrativos, financieros y logísticos) son parte del proceso de cierre formal del proyecto. Se capturan los resultados específicos del proyecto (Ej: alcance planificado versus real, hitos planificados versus reales). A través de la colaboración de los GPIs, los resultados del proyecto se revisan hasta lograr un acuerdo de que el proyecto está listo para su cierre. El cierre del proyecto provee autorización para liberar los recursos del proyecto como personal y equipos. El informe de cierre de proyecto incluye: Aceptación final del producto/servicio, incluyendo la reafirmación de los planes de mantenimiento y soporte que resolverán los que suceda una vez que el equipo de proyecto se marche; Archivo de los artefactos del proyecto, incluyendo los datos de verificación de la calidad del proyecto, desempeño del producto/servicio, alcance, costes (presupuesto) y calendario; Redistribución de recursos; Identificación de lecciones aprendidas del proyecto; Establecimiento de plan de actividades post-implantación; Uso del Informe de Cierre de Proyecto Visión Dentro del MRF framework, el informe de cierre de proyecto es un artefacto clave en la fase de ejecución del proyecto. El uso de este informe, que se encarga de la aceptación final del producto/servicio, asume que los representantes de los GPIs han aprobado previamente que el PMC-Instrucciones-10IFP-1.0 Página 1 Máster en Ingeniería de Software Proyecto Final de Máster – MRF Framework INSTRUCCIONES INFORME FINAL DEL PROYECTO Versión 1.0 | 30-SEP -2008 producto/servicio está listo para ser puesto en producción al haber firmado la aceptación previo a implantar. El uso de este informe de cierre del proyecto asume que la información del proyecto ha sido analizada y revisada a lo largo del ciclo de vida del proyecto. Los representantes de los GPIs deben utilizar esta información durante el cierre del proyecto. El informe debe ser desarrollado a través de colaboración con el personal de las áreas involucradas, clientes, personal técnico y otros GPIs responsables por el éxito del proyecto. Como un esfuerzo colaborativo, distintos individuos con diferentes funciones en el proyecto tendrán apreciaciones diversas con respecto a los resultados del proyecto. Por tanto, un aspecto crítico de elaborar el informe de cierre del proyecto es tener un acuerdo conjunto en los tipos, contenidos y precisión de los datos de cierre. Se debe buscar respuesta a las siguientes preguntas: ¿Se puede ya disponer de los recursos asignados al proyecto? ¿Se ha establecido ya un periodo de garantía?. Las actividades de cierre del proyecto deben ocurrir en cualquier punto una vez que el proyecto termina, independientemente de la razón por la cual termina. Esto puede darse por diferentes razones, incluyendo la conclusión del proyecto, conclusión de una fase, terminación temprana por fallas, etc. La información utilizada para elaborar el informe debe mantenerse en una ubicación separada y ser utilizada como entrada para la revisión de fin de fase del cierre del proyecto. El uso del informe de cierre de proyecto asume que existe un proceso de gestión de no conformidades. Las no conformidades abiertas documentadas como parte del cierre del proyecto son gestionadas, controladas, y cerradas basadas en éste proceso. Aplicabilidad El informe de cierre de proyecto debe ser desarrollado para cualquier proyecto. Gobierno y Alcance El gerente de proyecto debe colaborar estrechamente con el auspiciante ejecutivo y el auspiciante técnico para desarrollar y asegurar la terminación del informe. El auspiciante ejecutivo y auspiciante técnico deben aceptar la responsabilidad de realizar el cierre formal del proyecto y sobre los posibles impactos en las operaciones de negocio. Sección 1 Información General Completar la información general del proyecto. Especificar información de contacto. PMC-Instrucciones-10IFP-1.0 Página 2 Máster en Ingeniería de Software Proyecto Final de Máster – MRF Framework INSTRUCCIONES INFORME FINAL DEL PROYECTO Versión 1.0 | 30-SEP -2008 Sección 2 Lista de Verificación de Aceptación Final La lista de verificación advierte al equipo de proyecto y a los representantes de los GPIs como manejar formalmente y llegar a un acuerdo con respecto al cierre. Como parte de la entrega del proyecto, los representantes de los GPIs deben aceptar formalmente que el producto/servicio, basados en los resultados operacionales a la fecha, han satisfecho suficientemente las metas de negocio y objetivos de proyecto establecidos. El proceso de cierre del proyecto ayuda a asegurar un acuerdo de que todas las novedades de recursos, contractuales, presupuestarias y de desempeño han sido resueltas aceptablemente antes de que el equipo de proyecto se disuelva. El cierre representa la autorización para liberar los recursos del proyecto como personal y equipos. Para cada respuesta “no” en la lista de verificación, incluir una no conformidad en la sección de no conformidades abiertas. Resolver las respuestas “no” como parte del proceso de gestión de no conformidades. Las no conformidades abiertas documentadas como parte del proceso de cierre son gestionadas, controladas y cerradas basadas en la gestión de no conformidades. Sección 3 Lista de Verificación de los Artefactos del Proyecto La lista de verificación guía al equipo de proyecto para que el archivo de la documentación del proyecto y de otros ítems haya sido resuelto formalmente. Al responder las preguntas ayudamos a asegurar un cierre de proyecto exitoso y comprensivo. Como parte de la entrega del proyecto, estos artefactos deben ser fácilmente referenciados para futuros proyectos o por no conformidades que puedan surgir durante la operación. El plan de gestión del proyecto describe el plan de cierre para el proyecto. El plan de gestión de la configuración identifica todos los ítems de configuración del proyecto. Los ítems de configuración del proyecto incluyen hardware, software, así como la información de gestión del proyecto como planes, presupuesto, documentación de usuario, documentación de operación y mantenimiento. A menos que se indique lo contrario, todos los ítems del proyecto (tal cual están identificados en el plan de gestión de la configuración) deben ser considerados y formar parte del cierre del proyecto. La ubicación de los ítems que no están bajo la gestión de la configuración debe ser identificada. Por ejemplo: órdenes de cambio, facturas, etc. Durante el cierre del proyecto, se lleva a cabo una evaluación final de que tan bien se ha desempeñado el equipo del proyecto en términos de calidad, desempeño del producto/servicio, alcance, costes, calendario y otros aspectos. Todos estos aspectos son la base para consultas futuras. Verificar que los datos de entrega del proyecto utilizados durante la gestión se adjuntan a los entregables del cierre de proyecto, identificados con su ubicación en el plan de gestión de PMC-Instrucciones-10IFP-1.0 Página 3 Máster en Ingeniería de Software Proyecto Final de Máster – MRF Framework INSTRUCCIONES INFORME FINAL DEL PROYECTO Versión 1.0 | 30-SEP -2008 la configuración, o identificados como un ítem que no está bajo control de la gestión de la configuración. Por cada respuesta “no” incluir una no conformidad en la sección de no conformidades abiertas y gestionarla con el proceso de gestión de no conformidades. Sección 4 Recursos En el cierre se reasignan y reubican los diferentes tipos de recursos del proyecto tales como personal y equipos. Incluir los recursos especificados en el plan de proyecto. Identificar planes para los recursos (Ej: transferir, reasignar, terminar contrato) y la fecha en que se hará efectivo. Rendir cuentas por todos los recursos utilizados en el proyecto. Sección 5 Lecciones Aprendidas Identificar las lecciones aprendidas específicamente en el proyecto. Las recomendaciones deben ser utilizadas para futuros proyectos de tamaño y alcance similar. Establecer las lecciones aprendidas en términos de un problema o no conformidad y las mejoras recomendadas para corregir problemas similares en el futuro. Describir brevemente el problema identificando la naturaleza, el origen y el impacto, incluyendo cualquier documentación del proyecto como referencia (Ej: plan de gestión, registro de no conformidades, etc) donde se describan más detalles. Las lecciones aprendidas deben ser comprensivas en términos del alcance. Por ejemplo, mejoras de procesos que beneficien las medidas de desempeño, así como cambios recomendados para gestionar la calidad del proyecto. Todos los aspectos del proyecto, desde la propuesta de proyecto hasta la evaluación final de cierre debe ser revisado en búsqueda de lecciones aprendidas. Otros ejemplos son: gestión del contrato, conversión de datos, entrenamiento y migración. Sección 6 Planes Post-Implantación Establecer claramente planes post-implantación para revisión y reporte antes del cierre del proyecto. En la fase de cierre del proyecto se encontrará más información acerca de las actividades post-implantación. Identificar las fechas y los responsables para iniciar y asegurar que se completen exitosamente las revisiones post-implantación. La revisión de los resultados de negocio y post-implantación es un proceso iterativo. El producto/servicio debe estar en producción por suficiente tiempo para evaluar de manera efectiva el impacto en las operaciones de negocio. Por tanto, identificar una frecuencia planificada para revisiones post-implantación. También es importante identificar fechas, individuos responsables y la frecuencia para iniciar y asegurar la aprobación de los resultados de revisión post-implantación. PMC-Instrucciones-10IFP-1.0 Página 4 Máster en Ingeniería de Software Proyecto Final de Máster – MRF Framework INSTRUCCIONES INFORME FINAL DEL PROYECTO Versión 1.0 | 30-SEP -2008 Sección 7 No Conformidades Abiertas Resumir cualquier no conformidad abierta y los planes de resolución dentro del contexto del cierre del proyecto. Estas no conformidades abiertas son generales para todo el proyecto. Pueden incluir las condiciones estipuladas en el cierre. Este escenario de cierre significa que el proyecto puede ser cerrado aún cuando existe esta no conformidad abierta. Por ejemplo, un representante de los GPIs puede aceptar que el producto/servicio sea el final solo si la no conformidad específica es resuelta (da conformidad con el resto). Identificar esta no conformidad junto con su plan de resolución. Las no conformidades abiertas incluyen las respuestas “no” a las listas de verificación de las secciones de aceptación final y artefactos del proyecto. Este escenario de cierre significa que el proyecto no puede ser cerrado hasta que estas no conformidades sean resueltas. Por ejemplo, el representante de los GPIs no acepta que el producto/servicio sea final (como parte de una o más respuestas “no”) hasta que las no conformidades específicas sean controladas hasta su cierre. El proceso de cierre del proyecto debe ser entonces retomado para asegurar que todas las no conformidades han sido resueltas y gestionadas hasta su cierre. Identificar esta no conformidad junto con su plan de resolución. PMC-Instrucciones-10IFP-1.0 Página 5