Saltar al contenido principal
LibreTexts Español

12.5: Cierre del Proyecto

  • Page ID
    66279
    • Anonymous
    • LibreTexts
    \( \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}}\)

    Objetivos de aprendizaje

    1. Describir los procedimientos para cerrar contratos.
    2. Describir los elementos y propósito del proceso de revisión posproyecto.
    3. Identificar los tipos de documentos que deben archivarse.
    4. Identificar los objetivos de la celebración de cierre del proyecto.

    Los miembros del equipo que estaban entusiasmados con el proyecto en sus primeras etapas pueden tener dificultades para mantener su enfoque para completar el proyecto. Puede que ya estén esperando con ansias el próximo proyecto. Poner fin a un proyecto requiere un estilo de gestión diferente que se centre en los detalles así como un análisis de las decisiones que se tomaron.

  • Contratos de Adquisiciones

    La última etapa del ciclo de adquisiciones del proyecto incluye el pago de las facturas y el cierre de los contratos de adquisiciones.

  • Contratos con Proveedores

    Los proveedores proporcionan materias primas que deben cumplir con los estándares de calidad. El equipo del proyecto deberá verificar los registros de las entregas realizadas y determinar que fueron de calidad aceptable. Si algún artículo fue rechazado por mala calidad o no entregado, el pago final se ajusta en consecuencia.

  • Listas de punzonado y pruebas de rendimiento

    Si un proveedor está brindando un servicio o construyendo algo para el proyecto, generalmente hay artículos que deben ser corregidos o errores que deben corregirse antes de que se complete el contrato. En un proyecto de software, las pruebas de rendimiento se ejecutan en el software, generalmente por las personas que van a usar el software, y se anotan las expectativas de rendimiento que no se cumplan. En ocasiones las expectativas no se captaron en el ámbito de trabajo del proyecto y en ocasiones el desempeño no cumplió con las expectativas establecidas en el alcance. Si los artículos no estaban en el alcance del trabajo y el propietario quiere que el trabajo se haga, entonces el propietario normalmente emite una orden de cambio. Si las expectativas estuvieran en el alcance del trabajo, el contratista sigue siendo responsable de completar la obra.

    En un proyecto para construir una casa nueva, el dueño podría pasar por la casa buscando artículos menores no completados por el contratista. Antes de cerrar el contrato, cualquier artículo menor que necesite ser reparado o terminado se coloca en una lista de ponches, que es una lista de todos los artículos encontrados por el propietario que aún quedan por hacer. El equipo del proyecto trabajará entonces en todos los elementos de la lista, construyendo un pequeño horario para completar el trabajo restante.

    Si el número de ítems en la lista de punzonado 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 punch list 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 puñetazos.

  • Transferir al Cliente o Patrocinador

    Si el producto del proyecto es un edificio, un sistema de software, o algo que deba ser operado y mantenido por otra persona, éste debe ser entregado a las personas que serán responsables de ello una vez finalizado el proyecto. Podrían realizar su propia inspección para determinar si el equipo del proyecto ha cumplido sus metas de calidad y que todos los elementos del proyecto están completos. Estas pruebas de desempeño suelen identificarse en el contrato original del proyecto.

  • 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 se pueda completar a tiempo.

    Si el proveedor ha cumplido con todas las obligaciones contractuales, incluyendo 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 entre el proveedor y el proyecto.

    Horas extras necesarias para completar el proyecto y ganar el pago final

    El proveedor de automatización de edificios dedicó personal adicional y les pagó salarios de horas extras para solucionar los problemas y resolverlos para que el edificio pudiera abrir a tiempo. Cuando el equipo del proyecto quedó satisfecho, aprobaron el sistema y el pago final.

  • Evaluaciones posteriores al 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 una manera muy informal.

  • Evaluación del Perfil del Proyecto

    Una de las primeras actividades fue crear un perfil de proyecto para determinar dónde tenían más probabilidades de ocurrir los desafíos. Si se utilizó el Índice de Complejidad de Darnall-Preston (DPCI), se revisa cada una de las evaluaciones de complejidad y se compara con eventos reales ocurridos durante el proyecto. El equipo explora los cambios en el nivel de complejidad durante la vida del proyecto y cómo el equipo manejó la complejidad durante la vida del proyecto. Aprender de este ejercicio desarrolla una experiencia que es útil para hacer el siguiente perfil de proyecto. La calificación DPCI se ajusta, si es necesario, para fines de referencia en futuros proyectos.

  • 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

    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 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.

  • Gestión Presupuestaria

    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. ¿Se produjeron eventos en el proyecto 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. Al cliente se le da la oportunidad de expresar satisfacción e identificar áreas en las que mejorar. A menudo, un gerente senior de la organización entrevista al cliente para desarrollar comentarios sobre el desempeño del equipo del proyecto.

  • Informes

    Los resultados de las evaluaciones posproyecto se resumen en reportes para uso externo e interno.

  • Stakeholders

    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 pueda ser recuperada 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
  • Celebración del Proyecto

    Un final simbólico de un proyecto puede ser una celebración final para marcar el final del proyecto y quizás la disolución del equipo. El final de un gran proyecto suele ser un momento para reflexionar. Los miembros del equipo del proyecto y las partes interesadas generalmente han invertido una gran cantidad de tiempo y energía emocional en el éxito del proyecto. Debido a esta inversión y por las estrechas relaciones que se desarrollan durante un proyecto, el cierre del proyecto suele ser triste. Los gerentes de proyecto están atentos al entorno del equipo del proyecto y utilizan las celebraciones y el reconocimiento del equipo para mejorar los efectos del cierre del proyecto.

    Esta es una oportunidad para mejorar la satisfacción del cliente y la satisfacción de los miembros del equipo. Se podrán otorgar premios o placas de reconocimiento a personas que hayan hecho una contribución destacada al proyecto. Celebrar y revisar los desafíos y éxitos del proyecto crea una memoria positiva del proyecto y refuerza el aprendizaje que se puede transferir a proyectos futuros. Los grupos o equipos pueden ser reconocidos y los casos en los que la confianza entre los miembros del equipo hizo una diferencia positiva pueden ser recompensados.

    El cliente puede ser elogiado por las contribuciones durante la planeación y ejecución del proyecto.

    Claves para llevar

    • Para cerrar contratos, se prueban los sistemas, se inspeccionan los materiales y se hacen listas perforadas de los trabajos a completar.
    • El propósito de la revisión posproyecto es examinar las decisiones que se tomaron con conocimiento parcial con la forma en que el proyecto realmente se desarrolló para aprender de la experiencia y mejorar las decisiones futuras. También se utiliza para identificar procesos que pueden mejorarse.
    • Los documentos originales del proyecto, como la carta, la declaración de alcance y el presupuesto, se almacenan. Se almacenan los documentos desarrollados durante el proyecto, como los acuerdos de cambio. Se guardan las revisiones posteriores al proyecto, incluyendo un resumen de las lecciones aprendidas y una descripción final del perfil del proyecto (calificación DPCI).
    • En la celebración de cierre del proyecto, se otorga comportamiento positivo para individuos, y grupos y se invita al cliente o patrocinador a hablar para hacer cumplir una sensación de satisfacción.

    Ejercicios

    1. ¿Por qué una revisión posterior al proyecto es valiosa para futuros proyectos?
    2. ¿Qué documentos deben archivarse?
    3. ¿Por qué el proyecto debería tener una celebración de liquidación?

    Internaliza tu experiencia de aprendizaje preparándote para discutir lo siguiente.

  • >Considere por qué sería importante retener una cantidad significativa para el pago final. Si está familiarizado con una situación en la que un contratista tuvo que gastar extra para arreglar o terminar artículos para completar un trabajo, describa por qué podría necesitar un incentivo financiero para hacer esos trabajos.

  • This page titled 12.5: Cierre del Proyecto is shared under a CC BY-NC-SA license and was authored, remixed, and/or curated by Anonymous.