Cerrar un proyecto: acta de entrega y pendientes
Una plantilla para comprobar entregables, transferir pendientes, probar accesos y archivar el proyecto sin confundir entrega, aceptación y cobro.
TL;DR: Un proyecto entregado todavía necesita una comprobación del receptor, pendientes con responsable y un archivo utilizable. El acta registra esas decisiones; no convierte el silencio en aceptación ni una factura emitida en dinero cobrado.
Contenidos
Cerrar un proyecto consiste en dejar el trabajo en manos de alguien que pueda utilizarlo y saber qué queda pendiente. Enviar el último archivo resuelve la entrega; no demuestra que el cliente lo haya comprobado, que pueda editarlo o que otra persona atienda la próxima incidencia. La herramienta de esta guía es un acta operativa de cierre, copiable al final, que distingue esas situaciones sin crear una ceremonia innecesaria.
Empieza después de entregar. La preparación del presupuesto ya debe haber definido los entregables y sus referencias. Recupera esa versión y los cambios acordados. No aproveches el cierre para introducir condiciones nuevas ni para pedir otra vez decisiones que ya quedaron documentadas.
Un archivo enviado no es un resultado comprobado
Para cada entregable, escribe qué necesita poder hacer el receptor. «Presentación enviada» describe tu acción. «La responsable abre la versión final y exporta una copia sin fuentes ausentes» describe una prueba. No hace falta probar todas las funciones de una aplicación: comprueba el uso acordado y las dependencias que podrían impedirlo.
La guía de cierre de proyectos de Asana incluye comprobaciones finales, traspaso y archivo. Aquí proponemos un registro más pequeño para servicios: entregable, evidencia, decisión y siguiente responsable. Es un criterio operativo propio, no una norma de certificación.
Mantén separados tres estados: entregado, verificado y pendiente. Si falta respuesta, conserva pendiente la comprobación. Un mensaje de «recibido» acredita recepción, no necesariamente conformidad con todo el trabajo. Identifica quién confirma por el cliente y enlaza su respuesta a la versión concreta que revisó.
Ejemplo: una entrega, tres situaciones distintas
Supuesto ficticio: una consultora entrega una presentación editable, un PDF y una hoja de cálculo que alimenta dos gráficos. No se presentan resultados de un cliente real.
| Referencia | Hecho observado | Decisión de cierre |
|---|---|---|
| D-01: PDF | El cliente abre el archivo y comprueba las páginas acordadas | Registrar la comprobación y su fecha |
| D-02: presentación | La persona receptora no puede editarla con su cuenta | Mantener pendiente el acceso; no retirar todavía el permiso que necesita el traspaso |
| D-03: hoja | Una cifra depende de un dato del cliente que aún falta | Registrar P-01: dato necesario, consecuencia y persona que lo aportará |
En P-01, identifica los IDs y versiones afectados por el dato de D-03, incluidos D-01 y D-02 si contienen esos gráficos. Cuando llegue el dato, regenera los gráficos y archivos afectados y actualiza el índice. Las nuevas versiones quedan pendientes de verificación por el receptor: registra responsable, evidencia y fecha; la comprobación anterior no las valida.
No pongas «todo terminado» encima de esta tabla. D-02 impide utilizar un entregable como se acordó. D-03 puede requerir continuar el proyecto o transferir el pendiente, según el efecto del dato y lo que las partes hayan decidido. El tamaño aparente de la tarea no decide esa diferencia.
Una transferencia de pendiente necesita que el nuevo responsable la acepte y sepa qué debe hacer. Escribir su nombre en una celda no demuestra aceptación. Si nadie asume P-01, el pendiente sigue perteneciendo al proceso de cierre y debe quedar visible.
Prueba los accesos antes de retirar los tuyos
Pide a la persona receptora que abra el paquete desde su propia cuenta y realice la tarea acordada. Un enlace que funciona para quien lo creó puede fallar para el cliente. Anota el recurso, la cuenta o rol propietario, el resultado y los permisos temporales que habrá que retirar después. No copies contraseñas en el acta.
Si utilizáis Drive, hay una distinción concreta: transferir una carpeta no cambia automáticamente el propietario de los archivos que contiene. Google también limita las transferencias en cuentas de trabajo o centros educativos a la misma organización. Comprueba el tipo de cuenta y la operación disponible antes de prometer un traspaso. Documentación oficial de Google Drive.
Cuando no sea posible esa operación, acordad otra forma de entrega permitida y verificad el resultado. No retires accesos de manera indiscriminada: una cuenta puede sostener otros proyectos o un servicio que sigue activo. Asigna quién revisará cada permiso y bajo qué condición.
El archivo tiene que servir a quien llega después
Prepara un índice breve: versión final, archivos editables acordados, instrucciones de uso, decisiones y pendientes. Separa el material final del descartado. Conserva las referencias necesarias conforme a las reglas aplicables al trabajo; esta guía no fija un plazo universal de conservación ni propone borrar documentación.
Una prueba útil consiste en pedir al siguiente responsable que localice el entregable y explique cómo actualizarlo sin consultar tu conversación privada. Si necesita preguntarte cuál de cuatro archivos es el bueno, falta una decisión en el índice. Para una agencia, el receptor puede ser otra persona del equipo, además del cliente.
Copia el acta y completa una fila por pendiente
Sustituye los corchetes. Usa D-01 para un entregable y P-01 para un pendiente; los identificadores solo unen referencias. Añade filas cuando sea necesario, sin mezclar varios asuntos bajo «últimos detalles».
Proyecto y referencia acordada: [documento y versión]Paquete final: [ubicación, versión y fecha]D-01: [entregable / prueba / evidencia / estado]P-01: [qué falta / consecuencia / próxima acción]Entregables afectados por P-01: [IDs / versiones / nueva verificación: responsable, evidencia y fecha]Responsable de P-01: [quién lo acepta / confirmación]Revisión de P-01: [fecha o condición acordada]Accesos: [propietario / prueba / retirada pendiente]Archivo: [índice / editables / instrucciones]Administración: [referencia / estado real / responsable]Continuidad: [canal / responsable / cobertura acordada]Decisión: [abierto / cierre con pendientes transferidos / cerrado]Confirmación: [persona / versión / fecha; o pendiente]Comunica qué termina y qué sigue
Un mensaje adaptable: «Te envío el paquete [versión] y el acta [referencia]. Falta [comprobación] por parte de [rol]. [Pendiente] continúa con [responsable que lo ha aceptado]. Confírmame [decisión concreta]. Hasta entonces, [estado real]».
Registra la situación administrativa aparte: factura preparada, emitida, pendiente o cobrada según evidencia. El cierre operativo no liquida por sí solo una obligación ni demuestra cobro. Conserva también las horas de esta fase en tu control de gastos; que lleguen después de la entrega no las hace desaparecer.
Si aparece una incidencia, enlázala al entregable y distingue corregir lo acordado de proponer trabajo nuevo. No inventes una cobertura de soporte al escribir el acta. Termina con un aprendizaje accionable: por ejemplo, probar permisos con el receptor antes de la próxima entrega, con un responsable asignado. El cierre queda resuelto cuando las decisiones y sus responsables pueden entenderse sin reconstruir toda la conversación.
¿Te ha sido útil este artículo?
Preguntas frecuentes
¿Enviar la entrega final basta para cerrar el proyecto?
No: distingue entrega, confirmación del destinatario y trabajo pendiente. Si no hay respuesta, la confirmación sigue pendiente; un acuse de recibo no demuestra la aceptación del trabajo.
¿Qué pasa si cambia un dato después de la confirmación?
Identifica y regenera los entregables afectados, actualiza el índice y pide comprobar las nuevas versiones. La confirmación de una versión anterior no valida la nueva.
