CtrlK
BlogDocsLog inGet started
Tessl Logo

metodologia-project-program-management

PMO governance backbone — portfolio tracking, phase gate management, resource orchestration, dependency control, and proposal QA validation across the entire discovery pipeline. Use when the user asks to "track the discovery", "manage the portfolio", "validate the proposal", "run governance check", "check phase dependencies", "coordinate resources", or mentions PMO, program management, portfolio governance, phase gates, proposal readiness, milestone tracking, or cross-phase dependency management. Works as the structural glue that holds the entire discovery pipeline together — from Phase 0 through Handover.

The canonical home for this skill is metodologia-project-program-management in JaviMontano/mao-discovery-framework

SKILL.md
Quality
Evals
Security

Project & Program Management: PMO Governance Backbone

Structural governance layer that manages the discovery pipeline as a formal program — tracking phases, gates, resources, dependencies, risks, and proposal readiness. Operates as the connective tissue between all 48 skills, ensuring nothing falls through cracks, phases don't skip prerequisites, and the final proposal is validated before client delivery.

Principio Rector

El descubrimiento sin gobernanza es improvisación disfrazada de metodología. Este skill impone la disciplina de programa sobre el pipeline: cada fase tiene prerequisites, cada gate tiene criteria, cada entregable tiene owner y fecha. No es burocracia — es la diferencia entre "hicimos un discovery" y "ejecutamos un programa de discovery confiable."

Filosofía de Gobierno

  1. Governance ≠ Burocracia. El gobierno existe para habilitar velocidad con confianza, no para frenar. Cada control debe justificar su existencia con un riesgo que mitiga.

  2. Trazabilidad Total. Cada decisión, cambio de alcance, riesgo materializado, y dependencia resuelta queda registrada. El programa se puede auditar en cualquier momento.

  3. Proposal QA = Quality Gate Final. La propuesta v1 no sale hasta que pasa una validación multidimensional que verifica coherencia técnica, viabilidad, completitud, y alineación con hallazgos del discovery.

Inputs

Parse $1 as project/program name. Detect discovery context from repo.

Parameters:

  • {MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
    • piloto-auto: Auto para tracking rutinario, HITL para decisiones de gate, cambios de alcance, y validación de propuesta.
    • desatendido: Cero interrupciones. Gates auto-evaluados. Supuestos documentados.
    • supervisado: Autónomo con reportes en milestones. Preguntas solo en gates y QA de propuesta.
    • paso-a-paso: Confirma antes de cada evaluación de gate y cada sección de QA.
  • {FORMATO}: markdown (default) | html | dual
  • {VARIANTE}: ejecutiva (~40%) | técnica (full, default)

When to Use

  • At program initiation (before Phase 0)
  • At every phase gate (G1, G2, G3, 3b checkpoint)
  • When tracking cross-phase dependencies
  • During proposal QA validation (pre-client delivery)
  • When resource conflicts arise across phases
  • For status reporting to stakeholders
  • When scope changes threaten timeline or quality

When NOT to Use

  • Single-phase quick assessments (< 2 phases)
  • Pure technical analysis (use domain-specific skills)
  • Post-delivery — use discovery-handover instead

Delivery Structure: 7 Sections

S1: Program Charter & Governance Framework

  • Program scope: which discovery phases are in scope, which are deferred
  • Governance model: decision rights matrix (who decides what, at what level)
  • Communication plan: cadence, channels, escalation paths
  • Phase dependency map: prerequisite chain across all 8 phases
PhasePrerequisitesGateGate CriteriaOwner
Phase 0: Stakeholder MappingProject kickoff—Map complete, power grid populatedDomain Analyst
Phase 1: AS-ISPhase 0 complete—10-section analysis deliveredTechnical Architect
Phase 2: Flow MappingPhase 1 complete—Domain taxonomy + 8-12 flowsDomain Analyst
Phase 3: ScenariosPhase 2 completeG1Scenario approved by committeeFull-Stack Generalist
Phase 3b: FeasibilityG1 passed3b checkpointFeasibility verdict + viability scorecardQuality Guardian
Phase 4: Roadmap + CostPhase 3b passed—Roadmap + cost drivers deliveredDelivery Manager
Phase 4b: Commercial ModelPhase 4 completeG2Commercial structure approvedData Strategist
Phase 5a: Functional SpecG2 passed—Spec complete + use cases validatedTechnical Architect
Phase 5b: Executive PitchG2 passedG3Pitch approved, investment case clearChange Catalyst
Phase 6: HandoverG3 passed—Handover package completeDelivery Manager

Diagrama requerido: Gantt chart (Mermaid) con timeline del programa completo, gates como milestones

S2: Phase Gate Management

Para cada quality gate, evalúa:

Gate Evaluation Protocol:

GATE EVALUATION: {gate_name}
════════════════════════════
Phase Completing: {phase}
Date: {date}

ENTRY CRITERIA:
  [ ] {criterion_1} — {status: ✅/⚠️/🔴}
  [ ] {criterion_2} — {status}
  ...

DELIVERABLES CHECK:
  [ ] {deliverable_1} — {completeness: complete/partial/missing}
  [ ] {deliverable_2} — {completeness}

EVIDENCE CHAIN:
  - {deliverable} → {finding} → {implication for next phase}

DEPENDENCIES RESOLVED:
  [ ] {dependency_1} — {status}

RISKS CARRIED FORWARD:
  - {risk_1}: {mitigation status}

VERDICT: PASS / CONDITIONAL PASS / FAIL
  Conditions (if conditional):
    1. {condition}
    2. {condition}

  Fail reasons (if fail):
    1. {reason} → {remediation}
  • G1 (Post-Scenarios): Escenario aprobado, riesgos aceptables, viabilidad presumida
  • 3b Checkpoint: Feasibility FEASIBLE o FEASIBLE WITH CONDITIONS, viability 🟢/🟡
  • G2 (Post-Commercial): Roadmap viable, cost drivers identified, commercial model selected
  • G3 (Pre-Handover): Propuesta v1 aprobada, pitch listo, spec completa

S3: Resource & Capacity Orchestration

  • Expert committee allocation: quién está en qué fase, % dedicación
  • Bottleneck detection: cuando un experto es prerequisito para >2 fases simultáneas
  • Skill activation tracking: qué skills del catálogo de 48 se han activado, cuáles están pendientes
ExpertCurrent Phase% AllocatedBottleneck RiskNext Phase Needed
Technical ArchitectPhase 1100%🟡 Phase 3 needs same expertPhase 3 (50%)
Domain AnalystPhase 080%🟢 Available for Phase 2Phase 2 (100%)
  • Capacity alerts: flag cuando un recurso está sobre-asignado (>100%)
  • Skill gap identification: si una fase necesita un skill que ningún experto domina

Diagrama requerido: Flowchart (Mermaid) mostrando flujo de recursos entre fases

S4: Cross-Phase Dependency Control

  • Input/output dependency matrix: qué produce cada fase, qué consume la siguiente
  • Data contract verification: los contratos inter-fase se cumplen?
  • Scope change impact: si algo cambia en Phase 1, qué fases downstream se afectan?
Source PhaseOutputConsumer PhaseContractStatus
Phase 1: AS-ISStack inventoryPhase 3b: Feasibilitytechnology_inventory.json✅ Delivered
Phase 2: Flow MappingDomain taxonomyPhase 4: Costscope_decomposition base⚠️ Pending
Phase 3: ScenariosApproved scenarioPhase 3b: Feasibilityscenario_claims.json⚠️ In Progress
  • Scope change log: every change to scope, with impact assessment
  • Dependency blockers: qué está esperando qué, y quién lo desbloquea

Diagrama requerido: Sequence diagram (Mermaid) mostrando flujo de datos entre fases

S5: Proposal QA Validation (Quality Gate Final)

SECCIÓN CRÍTICA — el validador final antes de que la propuesta llegue al cliente.

La Propuesta v1 se construye de los outputs de Phases 4-5b. Antes de enviar al cliente, pasa por una validación multidimensional:

Trazabilidad de Fallas QA → Fase Origen: Si una dimensión QA falla, la remediación se traza directamente a la(s) fase(s) responsable(s):

  • Coherencia falla → re-verificar Phase 3b (feasibility) y Phase 4 (roadmap)
  • Completitud falla → re-verificar fase productora del deliverable faltante
  • Viabilidad falla → re-verificar Phase 4 (magnitudes) y Phase 5b (pitch claims)
  • Alineación falla → re-verificar Phase 1 (AS-IS) y Phase 3 (scenarios)

5a. Coherencia Técnica

  • ¿El roadmap es coherente con el AS-IS y el escenario aprobado?
  • ¿Los cost drivers reflejan el scope real (no el original pre-cambios)?
  • ¿La spec funcional cubre todos los flujos mapeados?
  • ¿La feasibility aprobó lo que la propuesta propone?

5b. Completitud

  • ¿Todos los deliverables del manifest están presentes?
  • ¿Cada sección tiene profundidad suficiente (no stubs ni placeholders)?
  • ¿Los diagramas son consistentes entre deliverables?
  • ¿Las cross-references entre documentos resuelven correctamente?

5c. Viabilidad de Propuesta

  • ¿Lo que se promete en el pitch es respaldado por la spec y el roadmap?
  • ¿Los magnitudes de costo son razonables dado el scope?
  • ¿El timeline propuesto es realista dado las dependencias?
  • ¿Los riesgos están documentados y mitigados?

5d. Alineación con Hallazgos

  • ¿La propuesta aborda los problemas identificados en AS-IS?
  • ¿Los escenarios descartados están justificados?
  • ¿Los hallazgos de feasibility/viability se reflejan en guardrails?
  • ¿El commercial model es coherente con el valor identificado?
PROPOSAL QA SCORECARD
═════════════════════
Proyecto: {nombre}
Propuesta v1 — Validación Pre-Envío

| Dimensión | Score | Hallazgos | Acción |
|---|---|---|---|
| Coherencia Técnica | [X]/5 | {findings} | {action if <4} |
| Completitud | [X]/5 | {findings} | {action if <4} |
| Viabilidad | [X]/5 | {findings} | {action if <4} |
| Alineación | [X]/5 | {findings} | {action if <4} |

COMPOSITE: [X.X]/5.0

VEREDICTO: APROBADA / APROBADA CON CONDICIONES / RECHAZADA
  Threshold mínimo: 3.5/5.0 composite, ninguna dimensión <3

Condiciones (si aplica):
  1. {condición}

LISTA PARA ENVÍO A CLIENTE: SÍ / NO

S6: Status Reporting & Dashboard

  • Program health dashboard: RAG status por fase
  • Milestone tracking: planned vs actual por phase
  • Risk burn-down: riesgos abiertos vs cerrados a lo largo del programa
  • Decision log: todas las decisiones tomadas en gates, con rationale
PhaseStatusPlanned EndActual/ForecastVarianceRAG
Phase 0✅ CompleteDay 2Day 20🟢
Phase 1🔄 In ProgressDay 5Day 6 (forecast)+1 day🟡
Phase 3b⏳ Not StartedDay 10——⚪

Diagrama requerido: Timeline/Gantt (Mermaid) con estado actual del programa

S7: Continuous Governance & Lessons Learned

  • Retrospective por fase: qué funcionó, qué no, qué mejorar
  • Governance effectiveness: ¿los gates atraparon problemas? ¿cuántos issues se detectaron en QA vs post-envío?
  • Process improvement recommendations para futuros discoveries
  • Metric collection: cycle time por fase, gate pass rate, proposal QA score trends

Prompt Integration Protocol

El project manager es el backbone de governance que acompaña TODOS los prompts. Se activa implícitamente en cada ejecución de prompt.

Rol en Cada Prompt

PromptRol del PMSección Activada
00-plan-discoveryCo-autor: Program CharterS1 (Charter)
01-stakeholder-mapReceptor: RACI para trackingS3 (Resources)
02-brief-tecnicoMonitor: phase status updateS6 (Dashboard)
03-asis-analysisMonitor: dependency trackingS4 (Dependencies)
04-mapeo-flujosMonitor: data contract validationS4 (Dependencies)
05-escenariosGate evaluator: G1S2 (Gate Management)
06-solution-roadmapGate evaluator: G2, scope trackingS2 + S4
07-spec-funcionalMonitor: completeness trackingS6 (Dashboard)
08-pitch-ejecutivoQA validator: proposal coherenceS5 (Proposal QA)
09-handoverGate evaluator: G3, final QAS2 + S5 + S7
revisarExecutor primario: full QA auditS5 (Proposal QA)
evolucionarRe-validator: post-improvement QAS5 + S6
rescatarTriage: gate status assessmentS2 + S6

Skill Inventory (48 skills gestionados)

DominioSkillsCantidad
Discovery Pipelinediscovery-orchestrator, stakeholder-mapping, workshop-facilitator, asis-analysis, dynamic-sme, flow-mapping, scenario-analysis, technical-feasibility, software-viability, solution-roadmap, cost-estimation, commercial-model, functional-spec, executive-pitch, discovery-handover, mermaid-diagramming16
Architecture Designsoftware-architecture, architecture-tobe, enterprise-architecture, solutions-architecture, infrastructure-architecture, devsecops-architecture, design-system, functional-toolbelt8
Data Strategydata-science-architecture, bi-architecture, data-engineering, database-architecture, data-governance, data-quality, analytics-engineering7
Cloud & Mobilecloud-native-architecture, cloud-migration, mobile-architecture, mobile-assessment4
Engineering Excellenceapi-architecture, event-architecture, security-architecture, performance-engineering, observability5
Consulting & Qualityquality-engineering, testing-strategy, user-representative3
Governance & Riskproject-program-management, risk-controlling-dynamics2
Delivery & Brandhtml-brand, ux-writing, roadmap-poc3
TOTAL48

Asset Inventory

Todos los 48 skills tienen examples/ con:

  • sample-output.md — Output markdown de referencia (Acme Corp Banking Modernization)
  • sample-output.html — Output HTML branded (Design System CSS)
  • README.md — Índice de assets

Ubicación: plugins/metodologia-discovery-framework/skills/{skill-name}/examples/

Trade-off Matrix

DecisionEnablesConstrainsWhen to Use
Full governance (all sections)Maximum confidence, auditableOverhead en programas pequeñosDiscovery >3 phases, high-stakes
Lite governance (S1+S2+S5)Fast trackingPierde trazabilidad detalladaDiscovery ≤3 phases, fast-track
QA-only (S5)Focused proposal validationNo tracking historyWhen proposal exists, need validation
Gate-only (S2)Phase transition controlNo resource or dependency trackingSimple sequential pipeline

Assumptions & Limits

  • Requires discovery pipeline context (phases, deliverables, expert committee)
  • Gate criteria assume full pipeline variant; Quick Reference variant has fewer gates
  • Resource tracking is planning-level, not actual time tracking
  • Proposal QA validates coherence and completeness, NOT domain correctness (that's each skill's job)

Edge Cases

ScenarioResponse
Discovery runs out of order (phase skip)Flag as governance violation. Document rationale. Assess impact on downstream phases
Scope change mid-discoveryImpact assessment across all remaining phases. Re-estimate if >10% scope change
Expert unavailable for gate reviewDesignate alternate. If no alternate, escalate with documented risk
Proposal QA fails multiple dimensionsDo NOT send to client. Identify remediation per dimension. Re-run QA after fixes
Client requests deliverables before QAFlag risk. Offer "draft" watermark. Never mark as final pre-QA
Pipeline variant = Quick ReferenceAdapt to 3-phase subset. QA still mandatory for proposal

Validation Gate

  • Program charter with phase dependency map
  • Gate evaluation protocol applied at each quality gate
  • Resource allocation tracked with bottleneck alerts
  • Cross-phase dependencies mapped and monitored
  • Proposal QA scorecard complete (composite ≥3.5/5.0)
  • Status dashboard current with RAG indicators
  • Decision log maintained throughout program
  • Scope change log with impact assessments
  • Diagramas Mermaid: Gantt (programa), flowchart (recursos), sequence (datos)

Knowledge Graph

graph TD
    subgraph Core
        PPM[Project & Program Management]
    end

    subgraph Inputs
        I1[Discovery Pipeline Context] --> PPM
        I2[Phase Deliverables] --> PPM
        I3[Expert Committee] --> PPM
        I4[Scope Baseline] --> PPM
    end

    subgraph Outputs
        PPM --> O1[Program Charter]
        PPM --> O2[Gate Evaluations]
        PPM --> O3[Resource Tracking]
        PPM --> O4[Dependency Matrix]
        PPM --> O5[Proposal QA Scorecard]
        PPM --> O6[Status Dashboard]
        PPM --> O7[Lessons Learned]
    end

    subgraph Related Skills
        RS1[risk-controlling-dynamics] -.-> PPM
        RS2[pipeline-governance] -.-> PPM
        RS3[discovery-orchestrator] -.-> PPM
        RS4[discovery-handover] -.-> PPM
        RS5[cost-estimation] -.-> PPM
    end

Output Templates

Formato MD (default):

# Program Governance: {project_name}
## S1: Program Charter & Governance Framework
### Scope | Decision Rights | Communication | Phase Dependencies (Gantt)

## S2: Phase Gate Management
### Gate Protocol | G1 | 3b Checkpoint | G2 | G3

## S3: Resource & Capacity Orchestration
### Allocation Table | Bottlenecks | Skill Gaps (Flowchart)

## S4: Cross-Phase Dependency Control
### I/O Matrix | Data Contracts | Scope Change Log (Sequence Diagram)

## S5: Proposal QA Validation
### Coherencia | Completitud | Viabilidad | Alineacion | Scorecard

## S6: Status Reporting & Dashboard
### RAG | Milestones | Risk Burn-Down | Decision Log

## S7: Governance & Lessons Learned

Formato DOCX: Reporte formal de gobernanza PMO: charter con firmas, evaluaciones de gate documentadas, scorecard de propuesta con trazabilidad a fase origen, dashboard de estado con graficos de tendencia, y log de decisiones auditable.

Formato XLSX (bajo demanda):

  • Filename: {fase}_project_program_management_{cliente}_{WIP}.xlsx
  • Generado via openpyxl con MetodologIA Design System v5. Headers navy con texto blanco Poppins, formato condicional por RAG status y veredicto de gate (PASS/CONDITIONAL/FAIL), auto-filtros en todas las columnas, valores calculados sin formulas. Hojas: Phase Gate Status, Resource Allocation, Dependency Matrix, Proposal QA Scorecard.

Formato PPTX (bajo demanda):

  • Filename: {fase}_project_program_management_{cliente}_{WIP}.pptx
  • Generado via python-pptx con MetodologIA Design System v5. Slide master con gradiente navy, títulos en Poppins, cuerpo en Montserrat, acentos en gold. Máx 20 slides ejecutivo / 30 técnico. Notas del presentador con referencias de evidencia. Slides: Program Charter, Phase Dependency Map (Gantt), Gate Evaluation Scorecards, Resource Allocation, Dependency Matrix, Proposal QA Scorecard, Status Dashboard RAG.

Evaluacion

DimensionPesoCriterio (7/10 minimo)
Trigger Accuracy10%Se activa ante keywords de PMO, governance, portfolio, gate, proposal QA; no ante PM generico de proyectos
Completeness25%Las 7 secciones cubren charter, gates, recursos, dependencias, QA, dashboard, y retrospectiva
Clarity20%Gate criteria son binarios (PASS/CONDITIONAL/FAIL); QA scorecard tiene threshold numerico claro
Robustness20%Edge cases (phase skip, scope change, expert unavailable, multi-dimension QA fail) tienen protocolo
Efficiency10%Variante ejecutiva y modos operacionales permiten activacion parcial sin perder trazabilidad
Value Density15%Cada gate produce veredicto accionable; QA fallas se trazan a fase origen con plan de remediacion

Umbral minimo: 7/10 en cada dimension. Composite ponderado >= 7.0 para considerar el output aceptable.


Output Format Protocol

FormatDefaultDescription
markdownYesRich Markdown + Mermaid diagrams. Token-efficient.
htmlOn demandBranded HTML (Design System). Visual impact.
dualOn demandBoth formats.

Default output is Markdown with embedded Mermaid diagrams. HTML generation requires explicit {FORMATO}=html parameter.

Output Artifact

Primary: P-01_Program_Governance_{project}.md (o .html si {FORMATO}=html|dual) — Program charter, gate evaluations, resource tracking, dependency control, proposal QA scorecard, status dashboard, lessons learned.

| HTML | {fase}_Program_Governance_{proyecto}_{WIP}.html | Mismo contenido en HTML branded (Design System MetodologIA v5). Self-contained, WCAG AA, responsive. Tipo: Dark-First Executive. Incluye Gantt de programa con gates como milestones, proposal QA scorecard interactivo, y dashboard RAG de fases. |

Diagramas incluidos:

  • Gantt chart: timeline del programa con milestones de gates
  • Flowchart: flujo de recursos entre fases
  • Sequence diagram: flujo de datos inter-fase

Autor: Javier Montaño | Última actualización: 12 de marzo de 2026

Repository
JaviMontano/mao-pm-apex
Last updated
First committed

Canonical home

JaviMontano/mao-discovery-framework
In sync

since Aug 28, 2026

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.