Los cinco grupos de procesos de un proyecto, y dónde entra la IA en cada uno

Este seminario lo dicté por primera vez en 2021, dentro de un banco, con un proyecto real de cobranzas sobre la mesa. Cinco años después el método no ha cambiado ni un milímetro: un proyecto sigue siendo un esfuerzo temporal con principio, fin y entregables, y sigue atravesando los mismos cinco grupos de procesos del PMI.

Lo que sí cambió fue la caja de herramientas.

Hay tareas que en 2021 me tomaban una tarde y hoy me toman veinte minutos. Y hay otras —las que deciden si el proyecto se aprueba, si el alcance aguanta o si hay que parar— donde la herramienta no ayuda nada y donde delegarla es exactamente el error que uno no se puede permitir.

Este artículo cierra el seminario hasta el módulo 3. Primero el mapa completo. Después, fase por fase, qué le entrego a la IA, con qué instrucción, y dónde le quito las manos de encima.

El mapa, en una página

Antes de los cinco grupos de procesos hay algo que casi nadie distingue bien, y de ahí sale la mitad de los proyectos que fracasan: no todo lo que te encargan es un proyecto.

Esa tercera fila es la que importa. Si lo que te pidieron no tiene fin, no tiene entregable distinto a lo de ayer, o es simplemente la operación de siempre con más presión, no es un proyecto y gestionarlo como tal solo agrega ceremonia.

Y una vez que sí lo es, el camino completo es este:

Problema u oportunidad → idea de solución → evaluación → caso de negocio → aprobación → y ahí, recién ahí, arranca el ciclo de vida. Los cinco grupos de procesos —inicio, planeación, ejecución, monitoreo y control, cierre— ocurren después de la aprobación. Lo de antes se llama iniciativa, y confundir las dos cosas es la razón por la que tanta gente «empieza proyectos» que nunca tuvieron presupuesto.

Antes del proyecto: la iniciativa y el caso de negocio

Aquí todavía no hay proyecto. Hay un problema, una idea y alguien que tiene que convencer a un comité.

El caso de negocio es el documento que hace esa conversión. Lleva el problema con su causa y su impacto, la solución y por qué funcionaría, los beneficios cuantificados, las finanzas —CAPEX, OPEX, ROI, VPN, TIR, payback, proyectados a seis años desde un año cero— y un plan de ejecución con hitos y riesgos. El resumen ejecutivo va de primero y se escribe de último.

Dónde entra la IA. En tres cosas, y ninguna es «escribe mi caso de negocio».

La primera es ordenar lo que ya sabes. Tú conoces el problema, lo has vivido; lo que cuesta es convertir ese conocimiento desordenado en la estructura que el comité espera. Le entregas tus notas crudas —lo que falla, a quién afecta, qué se te ocurre— y le pides que las acomode en las siete secciones del caso de negocio, marcando explícitamente qué secciones quedaron vacías.

«Organiza estas notas en un caso de negocio con estas secciones: resumen ejecutivo, problema, solución, beneficios, finanzas, ejecución y riesgos. No inventes datos. Donde no tengas información, escribe exactamente qué falta y quién en la organización lo tendría.»

Esa última frase es la que hace el trabajo. Lo que te devuelve no es un caso de negocio: es la lista de lo que te falta averiguar, que es mucho más útil a esa altura.

La segunda es buscarle los huecos a tu propia idea. Pídele que actúe como el comité que va a decir que no.

«Eres el comité que aprueba o rechaza este caso. Hazme las cinco preguntas más incómodas que me vas a hacer en la presentación.»

En mi experiencia, tres de esas cinco son las que de verdad te van a hacer. Es el ensayo más barato que existe.

La tercera es escribir el resumen ejecutivo una vez que todo lo demás está. Eso sí lo hace bien, porque es resumir un texto que ya existe.

Lo que no le entregas: las cifras. Los beneficios cuantificados, el CAPEX, el OPEX y los supuestos salen de gente de tu organización que conoce los costos reales. Una IA te va a producir números que se ven perfectamente razonables y son inventados, y ese es el peor resultado posible en un documento cuyo propósito entero es que alguien comprometa plata.

1 · Inicio

Dos procesos, y uno solo se hace una vez en la vida del proyecto.

El acta de constitución es el documento que autoriza formalmente que el proyecto exista y le da al director la autoridad para usar recursos de la organización. Lleva el propósito, los objetivos medibles con sus criterios de éxito, la descripción de alto nivel y los límites, el riesgo general, el cronograma de hitos, los recursos financieros preaprobados, los interesados clave, quién decide si el proyecto tuvo éxito, los criterios de salida, y el nombre y nivel de autoridad del director y del patrocinador.

Buena parte de eso ya está en el caso de negocio. El acta no se escribe desde cero: se traduce.

Identificar a los interesados es el otro, y es el que más proyectos hunde cuando se hace rápido. No basta con listar nombres: la matriz útil tiene, por cada interesado, su interés en el proyecto, su nivel de influencia, qué va a contribuir y dónde va a resistirse. Esa última columna es la que casi nadie llena y la que explica la mitad de los bloqueos de los meses siguientes.

Dónde entra la IA. El acta desde el caso de negocio es una traducción de formato, y eso lo hace bien:

«Convierte este caso de negocio en un acta de constitución con estos campos: [la lista]. Si un campo no se puede llenar con lo que está en el documento, déjalo marcado como pendiente en vez de completarlo.»

Y para interesados, el uso que más me ha servido no es que los liste —esos los conoces tú— sino que te señale los que olvidaste:

«Este proyecto cambia el proceso de aplicación de pagos en cobranzas. Dame una lista de roles y áreas que suelen verse afectados por un cambio así y que la gente olvida incluir: áreas de control, soporte, quien recibe el reclamo cuando algo falla, quien mantiene el sistema después.»

Lo que devuelve son categorías, no personas. Las personas las pones tú. Pero la categoría «quién mantiene esto después de que el proyecto cierre» es justo la que no aparece en la primera lista de nadie.

Lo que no le entregas: el análisis de influencia y resistencia. Quién tiene poder real en tu organización, quién le debe un favor a quién y quién va a frenar el proyecto en el comité sin decirlo en voz alta es conocimiento político, no documental. No está en ningún texto que la herramienta pueda leer.

2 · Planeación

Es el grupo más grande y el que define si el resto se puede gestionar. Cinco bloques, en orden, porque cada uno es insumo del siguiente.

Requisitos. Lo que hay que levantar de todas las fuentes: requisitos del negocio, de los interesados, de la solución —funcionales y no funcionales— y del proyecto. Antes de entrar a la línea base tienen que ser inequívocos, medibles, comprobables, trazables, completos y coherentes. En enfoques ágiles esto es el backlog: épicas, historias de usuario, criterios de aceptación.

Alcance. Dónde empieza y dónde termina tu trabajo. Y se escribe SMART: específico, medible, alcanzable, relevante y con fecha. Un alcance que no se puede leer y saber si ya se cumplió no es un alcance, es una intención.

EDT. La descomposición jerárquica del trabajo en paquetes. La regla que más se incumple: la EDT se arma con entregables, no con tareas. El paquete de trabajo es el nivel más bajo donde todavía puedes estimar costo y duración.

Actividades y cronograma. Ahí sí las tareas: definir, secuenciar y estimar duración. Con hitos de duración cero, predecesoras y dependencias, y nivelación de recursos.

Costos y presupuesto. Dos fórmulas que caben en una servilleta y resuelven el 90% de los casos:

Costo de ejecución = costo del recurso × tiempo de la tarea
Presupuesto        = adquisiciones + costo de ejecución

En el seminario esto se hace construyendo un cuarto: ladrillos, cemento, arena, pintura, ventana, puerta y techo por un lado; dos contratistas a $16.000 la hora por el otro. Las adquisiciones dan $1.489.800, la ejecución $8.960.000, y el presupuesto $10.449.800. Es un ejercicio deliberadamente doméstico, porque el método es idéntico en un proyecto de cincuenta mil millones.

Dónde entra la IA. Esta es la fase donde más tiempo me ahorra, y por lejos.

Descomponer la EDT. Le das el alcance y le pides el primer nivel de descomposición. Lo que devuelve nunca es la EDT final, pero sí es un borrador contra el cual pensar, que es mucho más rápido que la hoja en blanco:

«Este es el alcance del proyecto: [texto]. Propón una EDT de tres niveles, organizada por entregables y no por tareas. Para cada paquete de trabajo del último nivel, di qué entregable produce.»

La condición «por entregables y no por tareas» hay que ponerla explícita, porque por defecto te devuelve una lista de actividades — que es precisamente el error clásico.

Encontrar lo que falta en la EDT. Mejor uso todavía: le pasas la EDT que armaste tú y le pides el hueco.

«Esta es mi EDT. ¿Qué entregables típicos de un proyecto de este tipo no están? Piensa en capacitación, documentación, migración de datos, pruebas, puesta en marcha y soporte post-salida.»

Convertir paquetes en actividades y proponer un secuenciamiento inicial con predecesoras. El cronograma que sale está mal, siempre. Pero está mal de una forma concreta que puedes corregir, y eso es más rápido que construirlo de cero.

Redactar el alcance en SMART. Le entregas tu párrafo y le pides que señale qué le falta para ser específico, medible y con fecha. Aquí sí es bueno: es una revisión de forma contra un criterio claro.

Lo que no le entregas: las estimaciones. Ni de duración ni de costo. Una IA no sabe cuánto se demora tu equipo, no conoce la deuda técnica de tu sistema, no sabe que el proveedor siempre entrega dos semanas tarde ni que diciembre no cuenta. Te va a dar números que suenan bien y son ficción, y una línea base construida sobre ficción es peor que no tener línea base, porque te da confianza falsa durante meses.

La estimación sale del equipo que va a hacer el trabajo, de datos históricos, o de analogía con proyectos que tú conoces. Esos tres caminos requieren a alguien que estuvo ahí.

3 · Ejecución

Dirigir y gestionar el trabajo: asignar recursos, implementar los cambios aprobados, producir los entregables, y gestionar el conocimiento del proyecto. Y la parte que se subestima siempre: las comunicaciones.

La comunicación del proyecto no es mandar correos. Es una estrategia —quién necesita saber qué, con qué frecuencia y en qué formato— y después la ejecución de esa estrategia. El instrumento central es el PSR, el reporte de estado del proyecto, que lleva información cuantitativa, información cualitativa y los temas específicos del proyecto.

Dónde entra la IA. Aquí el ahorro es de horas por semana, y es el uso menos glamoroso y más rentable.

Redactar el mismo avance para tres audiencias distintas. El estado del proyecto es uno, pero el comité directivo, el equipo técnico y el usuario final necesitan tres versiones. Esa traducción es trabajo mecánico:

«Este es el estado del proyecto esta semana: [notas]. Escríbelo en tres versiones: un párrafo para el comité directivo centrado en riesgos y fechas; una lista para el equipo técnico centrada en bloqueos; y tres líneas para el usuario final sobre qué va a cambiar y cuándo. No agregues información que no esté en mis notas.»

Resumir reuniones y sacar los compromisos. De una transcripción o de tus notas, extraer qué se decidió, quién quedó responsable de qué y para cuándo. Pídele explícitamente que separe lo decidido de lo que quedó en el aire — esa separación es la que hace útil el acta.

Redactar la comunicación difícil. El correo de «se corrió la fecha» tiene una forma que funciona: el hecho primero, la causa después, la acción y la nueva fecha al final, sin adjetivos. Pedir tres versiones y escoger es más rápido y sale mejor que escribirlo a la primera cuando uno está molesto.

Lo que no le entregas: la decisión de qué comunicar y a quién. Ocultar un retraso o anunciarlo con una semana de anticipación es una decisión de dirección, con consecuencias. La herramienta redacta; tú decides.

4 · Monitoreo y control

Ocurre a lo largo de todo el proyecto, en paralelo con la ejecución. Comparar el desempeño real contra el plan, evaluar si hace falta acción preventiva o correctiva, verificar riesgos, alimentar el informe de estado y los pronósticos, y —la que más se olvida— asegurar que el proyecto siga alineado con la necesidad de negocio que lo originó.

Dos conceptos que vale la pena tener claros, porque se confunden todo el tiempo:

• Riesgo: un problema que no se ha materializado y que podría afectar el proyecto.
• Issue: un riesgo que ya se materializó y está generando daño.

Y el indicador más usado para la salud del proyecto es el RAG —rojo, ámbar, verde—, que se mide por separado sobre cada restricción: alcance, costo y tiempo. El ámbar es precisamente el territorio de los riesgos: todavía no pasó, pero va para allá.

Dónde entra la IA. El mejor uso de toda la metodología está aquí, y es el que menos se menciona.

Detectar la desviación antes de que sea obvia. Le entregas la línea base y el avance real, y le pides que compare y señale dónde se están separando, con la magnitud de cada desvío. No para que decida: para que no se te pase ninguno.

«Esta es mi línea base de cronograma y este es el avance reportado. Dame todas las actividades donde la diferencia supere el 10%, ordenadas por impacto en la ruta crítica, y di cuáles de ellas tienen sucesoras.»

Convertir el seguimiento en el PSR. Ya tienes los datos; el PSR es darles forma. Eso lo hace bien y rápido.

Revisar la coherencia de tus propios semáforos. Un uso que me gusta mucho: pegarle el PSR terminado y preguntarle si los colores cuadran con lo que dice el texto. Es sorprendente la frecuencia con que uno pone verde en costo y tres párrafos abajo describe un sobrecosto.

Lo que no le entregas: poner el color. El RAG es un juicio de dirección, y es político además de técnico. Poner ámbar en un proyecto tiene consecuencias —se activan comités, se piden explicaciones— y esa decisión la toma quien responde por el proyecto. Una IA que «calcule» el semáforo a partir de umbrales te va a dar verde el día antes de que todo se caiga, porque los umbrales no saben que el único proveedor crítico acaba de renunciar.

5 · Cierre

El grupo que más se salta, y el que más valor deja para el siguiente proyecto.

Cerrar es: verificar que se cumplieron los criterios de culminación o salida, tener todos los documentos y entregables actualizados y los incidentes resueltos, conseguir la aceptación formal del cliente, asignar todos los costos al proyecto, cerrar las cuentas, reasignar al personal y los equipos, disponer del material sobrante, elaborar los informes finales y hacer la sesión de cierre.

La palabra importante es formal. Un proyecto que «ya terminó» pero cuyo entregable nadie aceptó por escrito sigue abierto, y vas a seguir recibiendo solicitudes sobre él durante meses.

Dónde entra la IA. Aquí hace algo que en la práctica casi nadie alcanza a hacer bien.

Las lecciones aprendidas de verdad. La sesión de lecciones aprendidas normalmente se hace de memoria, al final, cuando todos están cansados y solo recuerdan lo de las últimas dos semanas. Pero el proyecto dejó un registro completo: actas, PSR semanales, el registro de cambios, el de riesgos e issues. Entregarle todo eso y pedirle el patrón es un uso que no tiene sustituto manual razonable.

«Estos son todos los PSR y el registro de cambios del proyecto. ¿Qué tipo de desviación se repitió más? ¿En qué fase aparecieron los issues? ¿Qué riesgos identificamos al inicio que nunca se materializaron, y cuáles nos golpearon sin haberlos visto venir?»

Esa última pregunta —qué nos golpeó sin haberlo visto— es la lección aprendida que de verdad sirve para el siguiente proyecto, y es la que nunca sale de una reunión de memoria.

Redactar el informe final a partir del acta de constitución y los entregables aceptados, comparando lo prometido contra lo entregado.

Lo que no le entregas: la aceptación. La firma del cliente es un acto, no un documento.

Las cuatro donde yo no la usaría

Si de todo esto te llevas una sola sección, que sea esta.

1. Estimaciones que nadie va a validar. Es el riesgo más grande de todos, porque el resultado se ve bien. Una duración o un costo inventados se convierten en línea base, y contra esa línea base vas a medir el proyecto durante un año.

2. Decisiones de alcance. Qué entra y qué no entra es la decisión más cara del proyecto y depende de negociación con interesados, presupuesto y prioridad estratégica. La herramienta puede redactar el alcance que tú decidiste; no puede decidirlo.

3. Datos confidenciales en herramientas públicas. Nombres de clientes, cifras no publicadas, contratos, datos personales. Esto no es una recomendación de estilo: en Colombia los datos personales están bajo la Ley 1581 de 2012, y el hecho de que una herramienta sea cómoda no cambia el régimen. Antes de pegar algo, la pregunta es si ese texto podría salir de la empresa por otro medio. Si la respuesta es no, tampoco por este.

4. La relación con los interesados. El correo lo puede redactar. La conversación difícil con el patrocinador que quiere más alcance con el mismo presupuesto, no. Ese es el trabajo.

El patrón, si tuviera que resumirlo en una frase

En las cinco fases se repite lo mismo: la IA es buena transformando información que ya existe, y mala produciendo información que no existe.

Traducir un caso de negocio en acta, convertir notas en un PSR, reordenar una EDT, resumir cincuenta documentos en un patrón: todo eso es transformación, y ahí rinde. Estimar una duración, poner un semáforo, decidir un alcance, cuantificar un beneficio: todo eso es producir información nueva sobre un mundo que la herramienta no conoce, y ahí es donde hace daño.

El criterio para saber cuál es cuál no se aprende con la herramienta. Se aprende haciendo proyectos.

El reto del módulo

Construye y presenta el PSR de un proyecto. Con su información cuantitativa, su información cualitativa, los temas específicos y el RAG de cada restricción.

Si quieres usar la IA, úsala como se usa bien: arma tú el contenido y pídele las tres versiones para las tres audiencias.

Dónde sigue

Este artículo cierra el módulo 3 y con él los cinco grupos de procesos. Lo que falta del seminario es el módulo de metodologías ágiles, y el cierre completo a cámara.

Los módulos anteriores:

• Cómo nacen los proyectos — módulo 1: la diferencia entre proceso, iniciativa y proyecto, y cómo se arma un caso de negocio que pasa el comité.
• Cómo elegir el ciclo de vida de un proyecto — módulo 2: predictivo, iterativo, incremental, ágil e híbrido como puntos de una misma escala.

Una nota sobre cómo se escribió esto

Vale la pena decirlo, porque sería incoherente no hacerlo: este artículo se escribió usando exactamente el método que describe. La estructura, el orden de las fases y los límites salen de las memorias del seminario de 2021 y de veinte años de experiencia profesional, más de quince en el sector financiero. La redacción y la organización se trabajaron con una herramienta de IA.

Lo que no se delegó: qué va y qué no va, qué ejemplos son honestos, y las cuatro advertencias de arriba. Eso es el contenido, y el contenido no se puede delegar.

El caso de cobranzas que atraviesa el seminario es real y las cifras del proyecto no se publican: la multa de 300 millones ya es parte de la historia que cuento en público, pero los beneficios, el CAPEX y los retornos pertenecen al banco donde ocurrió.

Fuentes

• Guía del PMBOK, 6.ª edición — Project Management Institute
• Memorias del seminario Project Management, módulos I, II y III (2021)