top of page

Serie PM&IA (1.3): Creando el Project Charter usando Inteligencia Artificial

hace 7 días
15 min de lectura

Del Handover al Project Charter

En los artículos anteriores de la serie hemos recorrido los primeros pasos que recibe un Project Manager cuando un nuevo proyecto llega a sus manos.

  • Primero analizamos el contrato y la documentación disponible para entender qué se ha vendido: alcance, entregables, hitos, responsabilidades, restricciones y primeros riesgos.

  • Después llegamos al Handover Meeting, donde el equipo comercial transfiere a ejecución algo que normalmente no aparece completamente reflejado en el contrato: la historia de la negociación, las expectativas del cliente, los supuestos utilizados durante la oferta, decisiones tomadas para cerrar el acuerdo o determinados puntos sensibles que conviene conocer antes de empezar.


Ahora disponemos de dos perspectivas complementarias: lo que está escrito y lo que ocurrió durante la venta, pero seguimos teniendo un problema: toda esa información continúa repartida entre contratos, ofertas, anexos, notas, reuniones y conocimiento de distintas personas. Necesitamos convertirla en una primera visión común del proyecto. Ahí aparece el Project Charter.


Ingeniero con casco revisa un panel holográfico de Project Charter y IA en una oficina industrial futurista, con tono profesional.
Creando el Project Charter usando Inteligencia Artificial

El primer documento que mira al proyecto como un todo

Hasta este momento hemos estado recopilando y entendiendo información. El Project Charter cambia ligeramente la perspectiva. Ya no queremos analizar cada documento por separado, sino responder de forma breve a preguntas mucho más globales: ¿Por qué existe este proyecto?, ¿Qué queremos conseguir?, ¿Cuál es su alcance a alto nivel?, ¿Cuáles son sus principales entregables e hitos?, ¿Qué restricciones y supuestos conocemos?, ¿Qué riesgos importantes vemos desde el inicio?, ¿Quién patrocina el proyecto? y ¿Quién será responsable de dirigirlo?


El objetivo no es describir todavía cómo vamos a ejecutar cada detalle. Para eso tendremos posteriormente la planificación y otros documentos de gestión. El objetivo es establecer una visión de alto nivel del proyecto.


¿Por qué no lo hemos hecho antes?

Podríamos haber intentado generar el Project Charter nada más recibir el contrato. Pero probablemente habría sido un documento bastante pobre. Después del Contract Review y del Handover disponemos de mucho más contexto. Conocemos no solo las obligaciones contractuales, sino también parte de las decisiones, expectativas, riesgos y condicionantes que dieron forma al proyecto.


Además, el Project Charter tiene una importancia especial dentro de Project Management: no es simplemente un resumen del proyecto. Es el documento que autoriza formalmente su existencia y proporciona al Project Manager la autoridad necesaria para aplicar recursos de la organización a las actividades del proyecto.


Esto introduce una diferencia importante respecto a lo que hemos hecho hasta ahora. Hasta aquí hemos estado entendiendo el proyecto. Con el Project Charter empezamos a formalizarlo como proyecto.


Y todavía no necesitamos Inteligencia Artificial

Aunque esta serie trate precisamente sobre Project Management e IA, antes de utilizarla necesitamos entender qué estamos intentando construir. Sin comprender qué es un Project Charter, qué función cumple y qué información debería contener nos permitiría obtener un documento aparentemente profesional… pero difícilmente podríamos saber si es realmente bueno.


Así que primero vamos a hacer un pequeño recorrido por el propio concepto de Project Charter. Después veremos qué información necesitamos para construirlo y, entonces sí, utilizaremos Inteligencia Artificial para transformar todo el conocimiento que hemos recopilado hasta ahora en un primer borrador estructurado.


Porque en PM&IA la idea sigue siendo la misma:

Primero entendemos qué debe hacer el Project Manager. Después vemos cómo puede ayudarle la IA.

Qué es realmente un Project Charter

Si buscamos una definición formal, el Project Charter es el documento que autoriza formalmente la existencia de un proyecto y otorga al Project Manager la autoridad necesaria para utilizar recursos de la organización en las actividades del proyecto.


Pero llevemos esa definición a algo más cercano al trabajo diario. Un Project Charter debería permitir que alguien con conocimiento de la organización, pero que no haya participado en todas las conversaciones anteriores, pueda leer unas pocas páginas y comprender rápidamente qué proyecto tenemos entre manos y cuáles son sus principales reglas de juego.


No pretende explicar cómo vamos a ejecutar cada actividad. Tampoco sustituye al contrato, al cronograma, al presupuesto detallado, al registro de riesgos o al futuro Project Management Plan.

Su nivel es deliberadamente high-level.


¿Para qué sirve entonces?

Podemos entender el Project Charter como una fotografía del proyecto en el momento de su autorización. En ella deberían quedar suficientemente claros aspectos como:

  • el propósito y la justificación del proyecto;

  • los objetivos que se pretenden alcanzar;

  • los criterios de éxito principales;

  • el alcance y los entregables a alto nivel;

  • los principales hitos;

  • los supuestos y restricciones conocidos;

  • los riesgos iniciales más relevantes;

  • los stakeholders principales conocidos en este momento;

  • el sponsor del proyecto;

  • el Project Manager asignado y su nivel de autoridad.


No necesitamos todavía desarrollar cada uno de estos puntos hasta el último detalle. De hecho, hacerlo iría contra la propia naturaleza del documento. El Charter debe permitir entender el proyecto, no documentarlo entero.


¿Quién lo aprueba?

Otro punto importante es que el Project Charter no debería ser simplemente un documento que el Project Manager escribe para sí mismo. La autorización debe proceder de alguien con autoridad suficiente dentro de la organización, normalmente el Project Sponsor o la figura equivalente que pueda comprometer recursos y respaldar formalmente el proyecto.


Esto también explica por qué resulta tan importante identificar claramente al sponsor desde el principio. El Project Manager puede participar activamente en su elaboración (y en nuestro caso veremos cómo puede apoyarse en IA para preparar el borrador), pero generar el documento y autorizar el proyecto son cosas diferentes.


Un documento breve por diseño

No existe una longitud universal que deba tener un Project Charter. Dependerá de la organización y de la complejidad del proyecto, pero su naturaleza ejecutiva nos da una buena pista.


Para un proyecto complejo podemos tener miles de páginas de especificaciones, decenas de planos, contratos, cronogramas, listas de equipos y documentación técnica. El Charter no intenta competir con todo eso. Intenta condensar lo verdaderamente importante.


Y podemos quedarnos con una regla bastante sencilla:

Si para entender el Project Charter necesitamos otro resumen del Project Charter, probablemente lo hemos hecho demasiado largo.

Qué información necesitamos antes de crear el Project Charter

Una de las ventajas de llegar al Project Charter después de los pasos anteriores es que no partimos de una hoja en blanco. Buena parte de la información necesaria ya debería estar disponible. El trabajo consiste ahora en seleccionar la realmente importante y consolidarla.


Los inputs del Project Charter

  • Contrato y oferta, para conocer alcance, compromisos, condiciones y principales hitos.

  • Anexos y documentación técnica, cuando contienen información relevante a nivel de proyecto.

  • Contract Review, con los entregables, riesgos, restricciones o inconsistencias que ya hayamos identificado.

  • Handover Meeting, especialmente para incorporar contexto comercial, expectativas del cliente, decisiones tomadas durante la negociación y riesgos conocidos.

  • Información económica, únicamente al nivel necesario para el Charter.

  • Información organizativa, como sponsor, Project Manager y estructura inicial del proyecto.

  • Información adicional del PM, incluyendo aclaraciones o decisiones que ya se hayan producido durante el arranque.


No necesitamos introducir todos los documentos completos en el Charter. Necesitamos extraer de ellos aquello que define el proyecto a alto nivel.


Diagrama de documentos y procesos conectados alrededor de un informe central, con iconos de reunión, firma, búsqueda y ajustes.
Información para crear el Project Charter

¿Y si todavía falta información?

Probablemente faltará. Estamos al principio del proyecto y sería extraño conocer ya todos sus detalles. Puede que una fecha todavía no esté confirmada, que algún responsable no haya sido designado o que exista una cuestión contractual pendiente de aclaración.


Eso no debería impedirnos preparar el Charter. Lo importante es distinguir entre: información confirmada y puntos todavía abiertos. Si un dato no está disponible, es preferible indicarlo como TBD, Pending Confirmation o incluirlo entre los Open Points, en lugar de completar el hueco con una suposición.


Esta será también una de las reglas fundamentales cuando introduzcamos la IA: si la información no existe, no queremos que la invente.


Con los inputs identificados, ya podemos definir qué queremos obtener de ellos: la estructura de nuestro Project Charter.


Qué debería contener nuestro Project Charter

Ya sabemos qué información podemos utilizar. El siguiente paso es decidir cómo convertirla en un documento breve, estructurado y realmente útil. No existe una única plantilla universal de Project Charter. Cada organización puede adaptarlo a su metodología, pero para nuestra serie PM&IA utilizaremos una estructura suficientemente completa para un proyecto industrial sin convertirla en un Project Management Plan.


Una estructura práctica

Nuestro Project Charter estará formado por los siguientes bloques:

Sección

Contenido

1. Project Identification

Nombre, cliente, sponsor, Project Manager y datos básicos del proyecto.

2. Project Purpose / Business Context

Por qué existe el proyecto y qué necesidad pretende cubrir.

3. Project Objectives

Qué resultados principales se esperan conseguir.

4. Success Criteria

Cómo podremos considerar que el proyecto ha cumplido sus objetivos.

5. High-Level Scope

Qué está incluido y cuáles son las principales exclusiones.

6. Main Deliverables

Entregables principales del proyecto.

7. High-Level Milestones

Fechas, eventos o condiciones contractuales especialmente relevantes.

8. Budget / Commercial Framework

Información económica de alto nivel que la organización considere apropiada.

9. Assumptions

Supuestos importantes sobre los que se está planteando el proyecto.

10. Constraints

Restricciones conocidas: plazo, presupuesto, recursos, tecnología, etc.

11. Initial High-Level Risks

Principales riesgos conocidos en este momento.

12. Key Stakeholders

Stakeholders que ya podemos identificar a alto nivel.

13. Project Sponsor

Persona o función que patrocina y respalda el proyecto.

14. Project Manager & Authority

PM asignado y autoridad que se le concede para dirigir el proyecto.

15. Open Points / Pending Clarifications

Información todavía pendiente de confirmar o resolver.

16. Approval

Aprobación formal del Project Charter.


High-level significa high-level

Este punto será importante cuando utilicemos IA. Si el contrato contiene 80 entregables, el Charter probablemente no necesita enumerar los 80. Si tenemos un Risk Register con 40 riesgos, tampoco necesitamos trasladarlos todos.


Queremos que la IA sintetice, no que copie. Por ejemplo, una restricción como: "La puesta en marcha debe completarse antes de la parada anual de producción del cliente." puede ser muy relevante para el Charter. El detalle de las actividades necesarias para conseguirlo pertenecerá posteriormente al cronograma.


Lo mismo ocurre con riesgos, costes, alcance o stakeholders: en este documento buscamos aquello que pueda condicionar el proyecto a nivel ejecutivo.


También dejamos espacio para lo que todavía no sabemos

La sección Open Points / Pending Clarifications tiene especial sentido al inicio de un proyecto industrial. Nos permite reconocer explícitamente que existen aspectos todavía pendientes sin convertirlos artificialmente en hechos.


Preparando la información con IA

Llegados a este punto ya tenemos dos cosas bastante claras:

  • sabemos qué información queremos utilizar como entrada;

  • sabemos qué estructura debe tener nuestro Project Charter.


Ahora sí tiene sentido introducir la IA. Pero hay una idea importante: no queremos pedirle que escriba un documento largo. Queremos exactamente lo contrario. El Project Charter debe seguir siendo un documento ejecutivo y de alto nivel. Por tanto, la IA tendrá que ayudarnos a seleccionar, condensar y priorizar.


El objetivo no es volcar información

Si proporcionamos a la IA contrato, oferta, notas del Handover, riesgos iniciales y otra documentación, una mala instrucción podría producirnos varias páginas por cada apartado. Eso no nos serviría. Lo que buscamos es algo mucho más parecido a esto:

documentación extensa
↓
selección de información relevante
↓
síntesis de alto nivel
↓
Project Charter breve y estructurado

La IA debe actuar como un filtro de consolidación, no como una fotocopiadora de contenido.


Qué le vamos a pedir exactamente

Para cada sección del Charter queremos solo la información esencial.

Por ejemplo:

  • Project Purpose: unas pocas líneas.

  • Project Objectives: varios objetivos claros y concretos.

  • High-Level Scope: resumen breve de lo incluido y excluido.

  • Main Deliverables: únicamente los principales.

  • Milestones: solo los hitos realmente relevantes.

  • Risks: unos pocos riesgos de alto impacto.

  • Stakeholders: solo los más importantes en este momento.

  • Open Points: únicamente aquellos que puedan condicionar el arranque del proyecto.


Pilas de papeles se digitalizan en un cubo de datos y generan un informe; iconos azules y fondo blanco, estilo tecnológico.
Primero consolidar, después redactar

Primero consolidar, después redactar

Podemos utilizar la IA directamente para generar el documento final, pero conceptualmente el proceso que queremos que realice tiene dos pasos:

1. Analizar las fuentes disponiblesIdentificar qué información corresponde realmente a cada sección.

2. SintetizarlaTransformarla en una versión breve, ejecutiva y comprensible.


Esto reduce además un riesgo habitual: que el modelo dé demasiada importancia a un detalle simplemente porque aparece muchas veces en la documentación.


Y mantendremos una condición muy clara:

No inventar información ausente.

No necesitamos que la IA haga que el documento parezca completo. Necesitamos que nos ayude a que el documento sea fiable.


Prompt PM&IA - Generando el Project Charter

Ahora ya podemos construir el prompt que utilizaremos para generar el primer borrador del Project Charter. La idea es sencilla: proporcionamos a la IA toda la información relevante que tengamos disponible y le pedimos que la transforme en un documento breve, ejecutivo, estructurado y de alto nivel.


No queremos que reproduzca toda la documentación del proyecto. Queremos que la sintetice.

Prompt PM&IA

You are assisting a Project Manager preparing the Project Charter for the project [NOMBRE PROYECTO]

The input may include:
- contract documentation
- commercial offer
- technical annexes
- outputs from previous contract review
- handover meeting notes
- identified risks
- preliminary stakeholder information
- commercial context
- project constraints
- project assumptions
- project milestones
- available budget or commercial information
- additional notes provided by the Project Manager

Your task is to analyze all the provided information and generate a concise, executive-level Project Charter.

The document must remain high-level and should not become a detailed project plan.

Use the following structure:
1. Project Identification
2. Project Purpose / Business Context
3. Project Objectives
4. Success Criteria
5. High-Level Scope
6. Main Deliverables
7. High-Level Milestones
8. Budget / Commercial Framework
9. Assumptions
10. Constraints
11. Initial High-Level Risks
12. Key Stakeholders
13. Project Sponsor
14. Project Manager & Authority
15. Open Points / Pending Clarifications
16. Approval

For each section:
- include only the most relevant information
- keep the content short and executive
- avoid unnecessary detail
- summarize rather than copy source documents
- do not include information that belongs in detailed project planning documents
- do not invent missing information
- clearly mark unknown or unconfirmed information as TBD, Pending Confirmation or Open Point

Additional rules:
- Do not make legal interpretations.
- Focus on project management implications.
- Prefer clarity over completeness.
- If several pieces of information conflict, highlight the inconsistency instead of choosing one.
- If a detail is too specific for a Project Charter, omit it.
- Keep the overall document concise enough to be reviewed quickly by senior stakeholders.

The objective is to produce a first draft of the Project Charter that the Project Manager can review, validate and submit for approval.

Qué estamos haciendo realmente con este prompt

Aunque a primera vista parece que simplemente estamos pidiendo a la IA que “escriba un Charter”, en realidad estamos definiendo cuatro comportamientos muy concretos: analizar, seleccionar, sintetizar y estructurar.


La IA debe resistirse a la tentación de rellenar páginas. Si encuentra veinte riesgos, debe seleccionar los más relevantes a nivel ejecutivo. Si encuentra decenas de hitos, debe quedarse con los que realmente definan el proyecto. Si encuentra información contradictoria, debe mostrarla como punto abierto.


Tres páginas de un documento Project Charter con tablas y secciones en azul sobre identificación, objetivos, hitos y presupuesto.
Project Charter Draft generado en WORD

Una salida que podamos revisar rápido

El resultado ideal no debería parecer un informe técnico. Debería ser un documento que un sponsor, un Project Director o un miembro del Steering Committee pueda leer rápidamente y entender:

  • qué proyecto estamos autorizando;

  • qué queremos conseguir;

  • cuáles son sus principales límites;

  • qué puede condicionarlo;

  • quién lo liderará.


Y esto nos lleva al siguiente paso, porque aunque el borrador haya quedado perfecto, todavía no tenemos un Project Charter. Tenemos un draft generado con IA. El siguiente capítulo será precisamente sobre cómo convertir ese draft en un documento validado y aprobado.


Del borrador generado por IA al Project Charter aprobado

Hasta este punto la IA nos ha ayudado a transformar documentación dispersa en un primer borrador estructurado del Project Charter. Pero ese borrador todavía no es el documento final. La diferencia está en una palabra: validación.


La IA prepara, el Project Manager valida

Antes de dar el Charter por bueno, el Project Manager debería revisar al menos:

  • que el propósito del proyecto esté correctamente expresado;

  • que los objetivos reflejen realmente lo acordado;

  • que el alcance de alto nivel no introduzca interpretaciones nuevas;

  • que los hitos sean los correctos;

  • que los supuestos y restricciones estén bien identificados;

  • que los riesgos seleccionados sean realmente relevantes;

  • que los stakeholders principales sean los adecuados;

  • que los puntos abiertos estén claramente señalados.


Aquí es donde entra el criterio profesional. La IA puede resumir muy bien información compleja, pero no conoce el contexto organizativo completo ni puede sustituir la responsabilidad del Project Manager.


Resolver los TBD antes de aprobar

Si durante la generación del documento han aparecido campos como:

  • TBD

  • Pending Confirmation

  • Open Point

no deberían ocultarse. Al contrario: son precisamente una de las partes más útiles del borrador. Nos indican qué información sigue faltando y qué debería resolverse antes de considerar el Charter suficientemente maduro para su aprobación.


La aprobación cambia el estatus del documento

Una vez revisado, el Project Charter debe ser aprobado por la figura con autoridad suficiente dentro de la organización, normalmente el sponsor o equivalente. Ese momento es importante porque el documento deja de ser una simple consolidación de información y pasa a convertirse en una referencia formal del proyecto.


Podemos representar el flujo así:

IA genera borrador
↓
Project Manager revisa y corrige
↓
Se resuelven puntos abiertos críticos
↓
Sponsor valida
↓
Project Charter aprobado

Y entonces sí tenemos un punto de partida sólido

A partir de aquí ya contamos con una visión de alto nivel suficientemente clara del proyecto. No significa que todo esté definido, ni debería estarlo. Significa que ya tenemos una base común sobre la que continuar trabajando.


Un documento pequeño que utilizaremos muchas veces

Una vez aprobado, el Project Charter no debería convertirse en un documento que se guarda en una carpeta y no se vuelve a consultar. Su valor está precisamente en que concentra, en muy poco espacio, la información que necesitaremos durante buena parte del arranque del proyecto.


Nos servirá como referencia para preparar los siguientes pasos de la serie:

  • identificar y analizar stakeholders;

  • preparar el Internal Kickoff;

  • alinear al equipo con los objetivos del proyecto;

  • revisar riesgos iniciales;

  • construir la planificación;

  • mantener una referencia común sobre alcance, hitos y restricciones.


Una referencia ejecutiva durante el arranque

En proyectos industriales complejos, la documentación crece muy rápido. En pocas semanas podemos tener cronogramas, listas de equipos, matrices de responsabilidades, registros de riesgos, actas, especificaciones y decenas de documentos técnicos.


Frente a todo eso, el Project Charter mantiene una función sencilla: recordar qué proyecto estamos ejecutando y bajo qué condiciones generales. Por eso conviene mantenerlo breve. Cuanto más detalle introduzcamos, más rápido quedará desactualizado y menos útil será como documento ejecutivo.


Nota PM&IA sobre los prompts

El prompt utilizado en este artículo está pensado como punto de partida, no como una plantilla cerrada. Cada organización puede tener su propia estructura de Project Charter, utilizar otra terminología o exigir campos adicionales. Por eso, lo normal será adaptar el prompt a la metodología interna de la empresa.


Podemos, por ejemplo:

  • utilizar una plantilla corporativa;

  • limitar la extensión de cada sección;

  • cambiar el idioma;

  • añadir campos propios;

  • excluir información sensible;

  • pedir determinados bloques en formato tabla.


También conviene recordar que el Project Charter formal suele generarse en formatos como Word o Excel, normalmente siguiendo una plantilla corporativa y un proceso de aprobación definido por la organización. Pero eso no impide que, a partir de la misma información, generemos otras formas de visualización.


Por ejemplo, podemos crear un HTML Briefing o un dashboard ejecutivo de una sola página con:

  • objetivos;

  • alcance;

  • hitos;

  • riesgos;

  • restricciones;

  • stakeholders clave;

  • puntos abiertos.

Esto puede resultar muy útil para reuniones, kickoffs o revisiones rápidas. Eso sí, nunca hay que olvidar que: "La visualización no sustituye al Project Charter formal aprobado". El documento original sigue siendo la referencia oficial. El WAR Briefing, dashboard, HTML o presentación son simplemente formas adicionales de consumir la misma información de manera más rápida y visual.


La idea PM&IA sigue siendo la misma: No se trata solo de generar documentos con IA, sino de transformar la información del proyecto en formatos útiles para cada necesidad.


Prompt PM&IA - Visualizando el Project Charter como WAR Briefing

Una vez tenemos el Project Charter, podemos reutilizar su contenido para crear una versión visual y ejecutiva que facilite su consulta rápida.

Por ejemplo:

You are assisting a Project Manager.
Using the Project Charter provided below, create a one-page HTML WAR Briefing that summarizes the project in a clear, visual and executive way.

Include:
- Project purpose
- Main objectives
- High-level scope
- Key milestones
- Main risks
- Main constraints
- Key stakeholders
- Open points / pending clarifications

Requirements:
- Keep the content concise.
- Use a professional executive style.
- Organize the information into clear visual blocks.
- Prioritize readability and rapid understanding.
- Use tables or highlighted sections where useful.
- Do not invent information.
- Do not add details that are not present in the Project Charter.
- The output must be a complete, self-contained HTML file.

The objective is to create a fast visual summary for project reviews, internal meetings or kickoffs.

De esta forma, el mismo Project Charter puede convertirse en una referencia formal y, al mismo tiempo, en una herramienta visual mucho más cómoda para el trabajo diario del Project Manager.


Pantalla de briefing de proyecto con paneles y viñetas; título PROJECT CHARTER - WAR BRIEFING, tonos azules y alertas de estado.
Project Charter - Briefing HTML

Conclusión - El proyecto ya tiene identidad

Con el Project Charter aprobado hemos alcanzado un punto importante. Hasta ahora hemos ido reuniendo piezas: contrato, oferta, documentacion técnica...


El Charter convierte todo eso en una visión común y formal del proyecto. No contiene todos los detalles ni pretende hacerlo. Su función es otra: dejar claro qué proyecto estamos poniendo en marcha, qué queremos conseguir y bajo qué condiciones generales vamos a gestionarlo.


El recorrido que hemos seguido en estos primeros artículos:

  • Primero entendemos lo que se ha firmado.

  • Después entendemos cómo se llegó hasta ahí.

  • Y finalmente consolidamos esa información en un documento de alto nivel que sirve como referencia para el arranque del proyecto.

La IA puede acelerar buena parte de este proceso, pero sigue existiendo una frontera muy clara:

La IA puede preparar el Project Charter. La organización es quien lo valida y autoriza.

🌐 Recursos LK PM&IA


Comentarios

© 2025 by Lozkorp                                                         

bottom of page