Saltar al contenido principal
LibreTexts Español

1.18: Finalización del Proyecto

  • Page ID
    68502
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    Cada proyecto tiene que terminar y de eso se trata la finalización del proyecto en la última fase del ciclo de vida del proyecto. El objetivo del proyecto es entregar lo que prometiste. Al entregar todo lo que dijiste que harías, te aseguras de que todas las partes interesadas estén satisfechas y que se hayan cumplido todos los criterios de aceptación. Una vez que eso suceda, tu proyecto puede terminar.

    La finalización del proyecto suele ser la fase más descuidada del ciclo de vida del proyecto. Una vez terminado el proyecto, es fácil empacar cosas, tirar algunos archivos en un cajón y comenzar a pasar directamente a la fase de inicio del siguiente proyecto. Aguanta. Aún no has terminado.

    Las actividades clave en la finalización del proyecto son recopilar registros de proyectos; difundir información para formalizar la aceptación del producto, servicio o proyecto; y realizar el cierre del proyecto. Como gerente del proyecto, deberá revisar los documentos del proyecto para asegurarse de que estén actualizados. Por ejemplo, tal vez se implementaron algunas solicitudes de cambio de alcance que cambiaron algunas de las características del producto final. La información del proyecto que esté recopilando durante esta fase debe reflejar las características y especificaciones del producto final. No olvides actualizar tus asignaciones de recursos también. Algunos miembros del equipo habrán ido y venido en el transcurso del proyecto. Es necesario verificar que se anoten todos los recursos y sus roles y responsabilidades.

    Una vez documentados los resultados del proyecto, solicitará la aceptación formal de las partes interesadas o del cliente. Están interesados en saber si el producto o servicio del proyecto cumple con los objetivos que el proyecto se propuso lograr. Si tu documentación está actualizada, tendrás a mano los resultados del proyecto para compartirla con ellos.

    Cierre de Contrato

    Los contratos llegan a su fin al igual que los proyectos llegan a su fin. El cierre del contrato se refiere a completar y resolver los términos de los contratos dejados para el proyecto. Apoya el proceso de finalización del proyecto porque el proceso de cierre del contrato determina si el trabajo descrito en los contratos se completó de manera precisa y satisfactoria. Tenga en cuenta que no todos los proyectos se realizan bajo contrato por lo que no todos los proyectos requieren el proceso de cierre del contrato. Obviamente, este proceso se aplica únicamente a aquellas fases, entregables o partes del proyecto que se realizaron bajo contrato.

    El cierre del contrato actualiza los registros del proyecto, detallando los resultados finales del trabajo en el proyecto. Los contratos pueden tener términos o condiciones específicos para su finalización. Debes estar al tanto de estos términos o condiciones para que la finalización del proyecto no se retrase porque te perdiste un detalle importante. Si usted está administrando el contrato usted mismo, asegúrese de preguntar a su departamento de compras si hay alguna condición especial que deba conocer para que su equipo de proyecto no demore inadvertidamente el cierre del proyecto del contrato.

    Uno de los propósitos del proceso de cierre del contrato es dar aviso formal al vendedor, generalmente en forma escrita, de que los entregables son aceptables y satisfactorios o han sido rechazados. Si el producto o servicio no cumple con las expectativas, el proveedor deberá corregir los problemas antes de emitir un aviso de aceptación formal. Antes de cerrar el contrato, cualquier artículo menor que necesite ser reparado o completado se coloca en una lista de ponches, que es una lista de todos los artículos encontrados por el cliente o equipo o gerente que aún quedan por hacer. Ojalá se hayan realizado auditorías de calidad durante el transcurso del proyecto, y se le dio al proveedor la oportunidad de hacer correcciones antes en el proceso que en la fase de cierre. No es buena idea esperar hasta el final del proyecto y luego generar todos los problemas y problemas en el vendedor a la vez. Es mucho más eficiente discutir problemas con su proveedor a medida que avanza el proyecto porque brinda la oportunidad de corrección cuando ocurren los problemas.

    Luego, el equipo del proyecto trabajará en todos los elementos de la lista de punzones, construyendo un pequeño horario para completar el trabajo restante. Si el número de ítems en la lista de punzones es demasiado grande o la cantidad de trabajo es significativa, el equipo del proyecto continúa trabajando en el proyecto. Una vez que la lista de punzones se vuelve más pequeña, el gerente del proyecto comienza a cerrar el proyecto, manteniendo solo suficiente personal y equipo para apoyar al equipo que está trabajando en la lista de punzones.

    Si el producto o servicio cumple con las expectativas del proyecto y es aceptable, se requiere una notificación formal por escrito al vendedor, indicando que el contrato está completo. Se trata de la aceptación formal y cierre del contrato. Es su responsabilidad como gerente de proyecto documentar la aceptación formal del contrato. Muchas veces las disposiciones para formalizar la aceptación y el cierre del contrato se detallan en el propio contrato.

    Si tienes un departamento de compras manejando la administración de contratos, ellos esperarán que les informes cuando el contrato esté completo y a su vez seguirá los procedimientos formales para que el vendedor sepa que el contrato está completo. Sin embargo, aún anotará la finalización del contrato en su copia de los registros del proyecto.

    Liberar al equipo del proyecto

    Liberar a los miembros del equipo del proyecto no es un proceso oficial. No obstante, cabe señalar que al concluir el proyecto, liberarás a los miembros de tu equipo de proyecto, y ellos volverán a sus gerentes funcionales o serán asignados a un nuevo proyecto. Querrás mantener informados a sus gerentes, u otros gerentes de proyecto, a medida que te acerques a la finalización del proyecto, para que tengan tiempo para planificar adecuadamente el regreso de sus empleados. Hágales saber con unos meses de anticipación cómo es el horario y qué tan pronto pueden planear usar a sus empleados en nuevos proyectos. Esto le da a los otros gerentes la capacidad de comenzar a planificar actividades y programar fechas de actividades.

    Pagos Finales

    El pago final suele ser más que un simple porcentaje de la obra que queda por completar. Completar el proyecto podría implicar arreglar los problemas más difíciles que son desproporcionadamente costosos de resolver, por lo que el pago final debe ser lo suficientemente grande como para motivar al proveedor a darle al proyecto una alta prioridad para que el proyecto pueda completarse a tiempo.

    Si el proveedor ha cumplido con todas las obligaciones contractuales, incluida la fijación de problemas y la realización de reparaciones como se indica en una lista de punzonado, el equipo del proyecto firma el contrato y lo envía al departamento de contabilidad para el pago final. Se notifica al proveedor que el último pago es definitivo y completa el acuerdo contractual con el proyecto.

    Evaluaciones Post-Proyecto

    Antes de que el equipo se disuelva y comience a enfocarse en el siguiente proyecto, se realiza una revisión para capturar las lecciones que se pueden aprender de este proyecto, a menudo llamado reunión o documento de lecciones aprendidas. El equipo explora lo que salió bien y captura los procesos para entender por qué salieron bien. El equipo pregunta si el proceso es transferible a otros proyectos. El equipo también explora lo que no salió bien y lo que la gente aprendió de la experiencia. El proceso no es para encontrar la culpa, sino para aprender.

    La gestión de la calidad es un proceso de mejora continua que incluye aprender de proyectos pasados y realizar cambios para mejorar el siguiente proyecto. Este proceso se documenta como evidencia de que las prácticas de gestión de la calidad están en uso. Algunas organizaciones tienen procesos formales para cambiar los procesos de trabajo e integrar las lecciones aprendidas del proyecto para que otros proyectos puedan beneficiarse. Algunas organizaciones son menos formales en el enfoque y esperan que los individuos aprendan de la experiencia y lleven la experiencia a su próximo proyecto y compartan lo que aprendieron con otros de manera informal. Sea cual sea el tipo de enfoque que se utilice, deben evaluarse los siguientes elementos y resumirse los resultados en reportes para uso externo e interno.

    Efectividad de confianza y alineación

    El liderazgo del proyecto revisa el efecto de la confianza, o la falta de confianza, en el proyecto y la efectividad de las reuniones de alineación para generar confianza. El equipo determina qué problemas podrían haberse previsto y mitigado y cuáles no podrían haberse predicho razonablemente. ¿Cuáles fueron las señales que se perdieron por el equipo que indicaban que estaba surgiendo un problema? ¿Qué podría haber hecho el equipo para predecir y prevenir mejor los problemas de confianza?

    Gestión de Horarios y Presupuesto

    El calendario original de actividades y el diagrama de red se comparan con el calendario real de eventos. Se revisan los eventos que provocaron cambios en el horario para ver cómo el uso de reservas de contingencia y flotación mitigó la disrupción causada por esos eventos. Se revisan las estimaciones originales del tiempo de contingencia para determinar si fueron adecuadas y si las estimaciones de duración y flotación fueron exactas. Estas actividades son necesarias para que el equipo del proyecto desarrolle experiencia en la estimación de elementos de programación en futuros proyectos, no se utilizan para culpar.

    Una revisión de las estimaciones presupuestales para el costo del trabajo programado se compara con los costos reales. Si las estimaciones son frecuentemente diferentes de los costos reales, se revisa la elección del método de estimación.

    Mitigación de riesgos

    Una vez finalizado el proyecto, las estimaciones de riesgo pueden ser revisadas y comparadas con los eventos que realmente tuvieron lugar. ¿Ocurrieron eventos que fueron imprevistos? ¿Qué señales existían que pudieron haber permitido al equipo predecir estos eventos? ¿La contingencia del proyecto fue suficiente para cubrir riesgos imprevistos? Incluso si nada salió mal en este proyecto, no es prueba de que la mitigación de riesgos fuera una pérdida de dinero, pero es útil comparar el costo de evitar el riesgo frente al costo de eventos inesperados para entender cuánto cuesta para evitar el riesgo.

    Contratos de Adquisición

    Se revisa el desempeño de los proveedores y vendedores para determinar si aún deben incluirse en la lista de proveedores calificados o vendedores. Se revisa la elección del contrato para cada uno para determinar si la decisión de compartir el riesgo estaba justificada y si la elección de incentivos funcionó.

    Satisfacción del cliente

    Se revisan las relaciones con el cliente y se discuten las decisiones sobre la inclusión del cliente en las decisiones del proyecto y las reuniones de alineación. Se le da al cliente la oportunidad de expresar satisfacción e identificar áreas en las que se podría mejorar la comunicación del proyecto y otros factores. A menudo, un gerente senior de la organización entrevista al cliente para desarrollar comentarios sobre el desempeño del equipo del proyecto.

    Se crea un informe general que proporciona una visión general del proyecto para proporcionar a las partes interesadas un resumen del proyecto. El informe incluye las metas y objetivos originales y declaraciones que muestran cómo el proyecto cumplió con esas metas y objetivos. Se resumen el desempeño en el cronograma y presupuesto y se brinda una evaluación de la satisfacción del cliente. Una versión de este informe se puede proporcionar al cliente como un stakeholder y como otro medio para obtener retroalimentación.

    Alta Dirección

    El informe a la alta dirección contiene toda la información proporcionada a los interesados en un breve resumen ejecutivo. El informe identifica prácticas y procesos que podrían mejorarse o lecciones aprendidas que podrían ser útiles en futuros proyectos.

    Archivo de documentos

    Los documentos asociados al proyecto deben ser almacenados en un lugar seguro donde puedan ser recuperados para futuras referencias. Deben almacenarse los contratos firmados u otros documentos que puedan ser utilizados en revisiones o demandas fiscales. Las organizaciones contarán con políticas de almacenamiento y recuperación de documentos legales que se aplican a los documentos del proyecto y deben seguirse. Algunos documentos del proyecto se pueden almacenar electrónicamente.

    Se debe tener cuidado para almacenar los documentos en una forma que se pueda recuperar fácilmente. Si los documentos se almacenan electrónicamente, se deben usar convenciones de nomenclatura estándar para que los documentos puedan clasificarse y agruparse por nombre. Si los documentos se almacenan en papel, se debe determinar la fecha de vencimiento de los documentos para que puedan ser destruidos en algún momento en el futuro. Los siguientes son documentos que normalmente se archivan:

    • Documentos chárter
    • Declaración de alcance
    • Presupuesto original
    • Cambiar documentos
    • Clasificaciones DPCI
    • Resumen del gerente: lecciones aprendidas
    • Clasificación final de DPCI

    Atribuciones de texto

    Este capítulo de Project Management es un derivado de los siguientes textos:


    This page titled 1.18: Finalización del Proyecto is shared under a CC BY-SA license and was authored, remixed, and/or curated by Adrienne Watt (BCCampus) .