Si la Sesión 2 nos enseñó a elegir nuestro camino (Ágil, Híbrido o Tradicional), la Sesión 3 nos ha enseñado a construir el vehículo. El Ing. Cesar Barriga Manrique fue directo: un proyecto que nace de un email o de una orden en el pasillo, es un proyecto huérfano destinado al fracaso.

Esta sesión se centró en el Grupo de Procesos de Inicio, la fase más crítica y a menudo ignorada. Aquí es donde diferenciamos una simple «buena idea» de un «proyecto real». ¿La herramienta clave? El Acta de Constitución del Proyecto (o Project Charter).

Investigando en sitios de referencia del PMI (como PMBC.es y el propio PMI.org), queda claro que este no es un documento burocrático, sino el documento fundacional que autoriza formalmente la existencia del proyecto y, lo más importante, otorga al Gerente de Proyecto la autoridad para aplicar los recursos de la organización.

Resumen Teórico: El Caso de Negocio y el Project Charter

Según el PMBOK®, el proceso de inicio tiene dos artefactos clave que a menudo se confunden, pero que son secuenciales:

1. El Caso de Negocio (Business Case): Es el documento PREVIO al proyecto. Responde el «POR QUÉ» económico. Demuestra el retorno de la inversión (ROI), la alineación estratégica y justifica por qué la empresa debe gastar dinero en esta iniciativa. Es un documento de negocio.
2. El Acta de Constitución (Project Charter): Una vez aprobado el Caso de Negocio, el Sponsor (Patrocinador) crea este documento. Es el primer documento OFICIAL del proyecto. Responde al «QUÉ» y al «QUIÉN».

Según los estándares del PMI, un Project Charter robusto debe incluir, como mínimo:

• Propósito y Justificación del Proyecto: (Heredado del Caso de Negocio).
• Objetivos Medibles y Criterios de Éxito: ¿Cómo sabremos que ganamos?
• Requisitos de Alto Nivel: No el detalle, sino las grandes fronteras.
• Riesgos de Alto Nivel: Los 3 o 4 «monstruos» que ya vemos en el horizonte.
• Hitos Clave (Summary Milestones): Un cronograma muy general.
• Presupuesto Resumido (Summary Budget): La orden de magnitud aprobada.
• Nombre del Project Manager y Nivel de Autoridad: «Tú estás a cargo y estas son tus facultades».
• Nombre del Sponsor: ¿Quién firma y aprueba esto?

Un proyecto sin este documento es un barco sin timón, sin capitán y sin mapa.

Ejemplos Prácticos: La Teoría en el Mundo Real

El Proyecto SAP (Caso de la Sesión): La intervención de Guadalupe sobre su proyecto de migración de SAP (de on-premise a la nube) es el ejemplo perfecto.

• El Caso de Negocio: Fue la «brecha» que la propia marca SAP impuso: «O migran a la nube o pierden soporte». El «por qué» era la supervivencia operativa.
• El Project Charter: El documento que el equipo de Guadalupe debe estar desarrollando ahora. Debe definir:
  • Objetivo: Migrar el 100% de los sistemas on-premise a SAP Cloud ALM.
  • Restricción: Cumplir con la fecha límite impuesta por SAP.
  • Riesgo de Alto Nivel: ¿Qué pasa si la migración de datos falla y la operación se detiene?
  • PM Asignado: Guadalupe (o su líder) con autoridad para solicitar recursos de los equipos de negocio.

El «Proyecto» Fantasma (Sin Charter): Un Gerente de Marketing le pide a tu equipo de TI «un pequeño formulario de contacto» para una nueva campaña. Tu equipo lo hace. A la semana siguiente, el gerente pide «que el formulario envíe un email». Luego, «que se conecte al CRM». Dos meses después, tienes a tres programadores dedicados a un «monstruo» que nadie autorizó, que no tiene presupuesto y que te está haciendo fracasar en tus proyectos reales. Eso es lo que evita un Project Charter.

Pon a Prueba tu Mentalidad de Project Manager

Ahora, te invito a la acción. Reflexiona con estas preguntas, diseñadas no para memorizar, sino para aplicar estos conceptos a tu realidad.

Abriendo el Debate

El Ing. Barriga y el PMI insisten en que el Project Charter es la piedra angular, firmado por un Sponsor. Sin embargo, en el mundo de la TI, muchos «proyectos» ágiles nacen de la necesidad inmediata del negocio.

Mi pregunta para el debate es: En una cultura Ágil o en una startup que se mueve a gran velocidad, ¿sigue siendo relevante un documento formal como el Project Charter? ¿O es visto como una «burocracia» que retrasa la entrega de valor?

¿Cómo manejan ustedes la autorización formal de proyectos en sus empresas?

«`