Stats
Actions
Tags
From thyrox
Use when formally closing a PMBOK project or phase. pm:closing — obtain final acceptance, document lessons learned by knowledge area, archive project artifacts, release resources, close contracts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/thyrox:pm-closingThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
> *"A project that ends without formal closure leaves loose ends: contracts still open, lessons not captured, and team members uncertain whether the work is truly done. Closing is the discipline of making endings official."*
"A project that ends without formal closure leaves loose ends: contracts still open, lessons not captured, and team members uncertain whether the work is truly done. Closing is the discipline of making endings official."
Ejecuta el Grupo de Proceso Closing de PMBOK. Obtiene la aceptación formal del producto del proyecto, documenta lecciones aprendidas por Knowledge Area, archiva los artefactos del proyecto, libera los recursos del equipo, y cierra contratos con proveedores.
THYROX Stage: Stage 11 TRACK/EVALUATE / Stage 12 STANDARDIZE.
Outputs clave: Final Acceptance Document · Lessons Learned · Project Archives.
Requiere: {wp}/pm-executing.md o {wp}/pm-monitoring.md con:
| Knowledge Area | Intensidad | Entregable clave |
|---|---|---|
| Integration Management | Alta | Close Project/Phase, Final Acceptance |
| Procurement Management | Alta | Close Procurements (si hay contratos) |
| Stakeholder Management | Media | Comunicación de cierre a todos los stakeholders |
| HR Management | Media | Release del equipo, performance evaluations |
| Communications Management | Media | Final project report |
| Risk Management | Baja | Cierre del Risk Register, lecciones de riesgos |
| Scope / Schedule / Cost / Quality | Baja | Solo validación final vs baseline |
La aceptación formal es el output más importante de Closing:
| Actividad | Descripción | Artefacto |
|---|---|---|
| Verificar deliverables vs scope baseline | Confirmar que todos los deliverables del WBS fueron completados | Scope verification checklist |
| Presentación de cierre al sponsor | Demostrar el producto terminado contra los objetivos del Charter | Presentación de cierre |
| Product Acceptance Sign-off | Firma formal del sponsor/cliente indicando que el producto cumple los requisitos | Final Acceptance Document |
| Outstanding issues log | Defectos o pendientes que se transfieren a operaciones o mantenimiento | Issues log de transferencia |
Criterios de aceptación:
| Tipo de criterio | Cómo verificar |
|---|---|
| Funcional | Todos los requisitos Must Have del scope baseline implementados |
| No funcional | Performance, seguridad, disponibilidad dentro de los umbrales acordados |
| Contractual (si aplica) | Todos los deliverables contractuales entregados y aceptados |
| Calidad | Defectos críticos = 0 en producción |
Las lecciones aprendidas son el activo más valioso del proyecto para proyectos futuros:
| Knowledge Area | Dimensiones a revisar |
|---|---|
| Integration | ¿El Charter fue realista? ¿El Change Control funcionó? ¿Los procesos de integración fueron eficientes? |
| Scope | ¿El scope creció? ¿El WBS fue suficientemente detallado? ¿Hubo scope creep no gestionado? |
| Schedule | ¿Las estimaciones fueron realistas? ¿El Critical Path fue gestionado activamente? ¿Las dependencias fueron identificadas? |
| Cost | ¿El presupuesto fue suficiente? ¿Las varianzas de costo fueron anticipadas? ¿El EVM detectó problemas a tiempo? |
| Quality | ¿Los estándares de calidad fueron claros desde el inicio? ¿Las inspecciones detectaron defectos temprano? |
| HR / Resource | ¿El equipo tuvo las competencias necesarias? ¿La planificación de recursos fue correcta? |
| Communications | ¿Los stakeholders estuvieron bien informados? ¿El plan de comunicaciones fue seguido? |
| Risk | ¿Los riesgos identificados ocurrieron? ¿Hubo riesgos no identificados? ¿Los planes de respuesta funcionaron? |
| Procurement | ¿Los proveedores entregaron según contrato? ¿Los contratos fueron bien estructurados? |
| Stakeholder | ¿Los stakeholders estuvieron engaged durante el proyecto? ¿Hubo resistencia al cambio? |
Formato recomendado por lección:
| Campo | Descripción |
|---|---|
| Knowledge Area | Área PMBOK afectada |
| Situación | Qué ocurrió (sin juicio, factual) |
| Impacto | Cómo afectó al proyecto (tiempo/costo/calidad/satisfacción) |
| Acción recomendada | Qué hacer diferente en el próximo proyecto |
| Aplicabilidad | Tipos de proyectos donde aplica esta lección |
Los documentos del proyecto deben estar organizados y accesibles para proyectos futuros:
| Categoría | Artefactos a archivar |
|---|---|
| Iniciación | Project Charter, Stakeholder Register inicial |
| Planificación | Project Management Plan y todos sus planes subsidiarios |
| Scope | WBS y WBS Dictionary, Scope Baseline |
| Schedule | Cronograma final vs baseline, Critical Path |
| Cost | Cost Baseline, EVM reports, cierre financiero |
| Calidad | Quality Management Plan, inspection reports, defect log |
| Riesgos | Risk Register final — riesgos que ocurrieron vs los que no |
| Comunicaciones | Actas de reuniones clave, reports de status, decisiones |
| Ejecución | Change log, issue log, performance reports |
| Cierre | Final Acceptance, Lessons Learned, este documento |
Regla de archivo: Si una lección aprendida no está archivada y accesible, no existe para el próximo proyecto.
El cierre formal incluye gestionar la transición del equipo:
| Actividad | Descripción |
|---|---|
| Performance evaluations | Evaluaciones de desempeño de los miembros del equipo |
| Knowledge transfer | Documentar conocimiento especializado antes de que el equipo se disperse |
| Release formal | Confirmar con los managers funcionales la liberación de los recursos |
| Recognition | Reconocimiento formal de las contribuciones del equipo |
Para proyectos con proveedores externos:
| Paso | Descripción |
|---|---|
| Verificar entregables contractuales | Confirmar que todos los deliverables del contrato fueron recibidos y aceptados |
| Procesar pagos finales | Asegurar que todos los pagos pendientes han sido procesados |
| Obtener cierre formal del proveedor | Documento de cierre o release del contrato |
| Documentar performance del proveedor | Para decisiones de futuras contrataciones |
Un reporte de cierre conciso para el registro de la organización:
| Sección | Contenido |
|---|---|
| Resumen ejecutivo | Qué se logró, en qué tiempo, con qué costo |
| Objectives achieved | Cada objetivo del Charter: logrado / parcialmente logrado / no logrado |
| Performance vs baseline | Schedule variance final, Cost variance final, calidad |
| Key decisions made | Decisiones importantes que afectaron el proyecto |
| Top lecciones aprendidas | 3-5 lecciones más aplicables a proyectos futuros |
| Recommendations | Para el equipo de operaciones o para el próximo proyecto |
Cierre completo (todos los siguientes deben cumplirse):
Cierre de fase (para proyectos multi-fase):
{wp}/pm-closing.md
usar template: closure-report-template.md
Al INICIAR este step:
methodology_step: pm:closing
flow: pm
pm_process_group: closing
Al COMPLETAR (proyecto cerrado):
methodology_step: pm:closing # completado — proyecto PMBOK cerrado
flow: pm
pm_process_group: closing
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub jcg-admin/iact-docs --plugin thyrox