Programas y Portafolios de Proyectos · Serie 13 · Semana 1 · Tema 1.3
Ya establecimos en qué se diferencian proyecto, programa y portafolio. Queda la pregunta práctica: si te nombran director de programa el lunes, ¿qué haces exactamente?
Porque el título suena a director de proyecto con más proyectos, y no lo es. Es un oficio distinto, con un entregable distinto, y quien lo ejerce como si fuera dirección de proyectos ampliada termina siendo un coordinador de reuniones caro.
El cambio de entregable
Un director de proyecto responde de un producto. Un director de programa responde de un beneficio: un cambio medible en la organización que ningún componente por separado puede producir.
La diferencia se nota en la pregunta que cada uno se hace al levantarse:
- Director de proyecto: ¿voy a entregar esto a tiempo y con el alcance acordado?
- Director de programa: ¿esto que estamos entregando va a producir el cambio que prometimos?
La segunda pregunta se puede responder «no» aunque todos los proyectos vayan en verde. De hecho, ese es el escenario más frecuente y el motivo de que el papel exista.
Las cinco cosas que hace realmente
1. Mantener vivo el caso de beneficios
Un programa se aprueba con una promesa: si hacemos esto, pasará aquello. Dieciocho meses después, el mercado cambió, el patrocinador se fue y nadie ha vuelto a mirar si la promesa sigue en pie.
El director de programa es quien tiene que preguntar, periódicamente y en voz alta: ¿esto sigue teniendo sentido? Es la pregunta más impopular del puesto, porque su respuesta puede ser cancelar algo en lo que ya se gastó dinero.
En la práctica se traduce en revisar el caso de negocio cada trimestre, no el avance: el avance ya lo reportan los proyectos.
2. Ordenar la secuencia
Cuatro proyectos que terminan a tiempo en el orden equivocado pueden no producir nada. Si el sistema entra antes de que la gente esté formada, durante tres meses se trabaja peor que antes.
El director de programa decide qué va antes de qué, y —más difícil— hace que un proyecto espere aunque esté listo. Ningún director de proyecto va a proponer eso; para él, esperar es puro costo.
3. Arbitrar dependencias y recursos
Cuando el proyecto A necesita algo del B, alguien por encima de los dos tiene que decidir. Sin ese árbitro, la decisión la toma quien tiene más carácter o más urgencia, que no es el criterio de la organización.
Aquí está buena parte del trabajo diario, y es el que menos se parece a dirigir un proyecto: no hay cronograma que actualizar, hay conversaciones que sostener.
4. Gestionar los interesados del nivel superior
Un programa toca varias direcciones. Sus interlocutores son directivos, no jefes de área, y esperan hablar con alguien de su nivel sobre impacto, no sobre porcentajes de avance.
Esto exige traducir: convertir el estado de doce proyectos en tres frases sobre si el beneficio prometido sigue en camino.
5. Cerrar el programa cuando toca
Y «cuando toca» no es el día que termina el último proyecto. Es cuando el beneficio se ha medido o cuando está claro que no se va a producir.
Un programa que cierra a la vez que su último componente no ha hecho la mitad de su trabajo.
Lo que NO debe hacer
Tan importante como lo anterior, porque es donde se pierde el papel.
No dirige los proyectos. Si el director de programa entra a decidir el cronograma de un componente, ha sustituido a su director de proyecto y ha dejado vacante el puesto que ocupaba él.
Esta es la deriva más común, y es comprensible: cuando un proyecto va mal, la tentación de meter mano es enorme, sobre todo si vienes de dirigir proyectos y se te da bien. Pero mientras estás arreglando ese cronograma, nadie está mirando el beneficio conjunto.
No es un consolidador de informes. Si su aporte es juntar doce estados en una presentación, el papel se puede automatizar y la organización no está obteniendo nada.
No arbitra solo cuando le llaman. Los conflictos que llegan solos son los ruidosos. Los caros son silenciosos: dos equipos que asumen cosas incompatibles y no lo saben.
La herramienta principal: el mapa de beneficios
Si el director de programa tiene un solo artefacto propio, es este. Encadena, de izquierda a derecha:
Entregables → capacidades → cambios en la forma de trabajar → beneficios → objetivo estratégico
Un ejemplo:
- Entregable: un portal de autoservicio.
- Capacidad: los responsables de área pueden dar de alta a alguien sin pasar por recursos humanos.
- Cambio: efectivamente lo hacen, y el procedimiento anterior se retira.
- Beneficio: el tiempo de incorporación baja de veinte a ocho días.
- Objetivo: absorber el crecimiento previsto sin ampliar el área administrativa.
La utilidad del mapa está en el eslabón del cambio, que es donde se rompen casi todos los programas. Entregar el portal es un proyecto. Que la gente lo use y se retire el procedimiento viejo no es de nadie, y sin eso el beneficio no aparece.
Dibujar ese mapa al inicio obliga a asignar dueño a cada eslabón, incluido ese.
Caso práctico: el programa que entregó todo y no cambió nada
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un programa de cuatro proyectos para reducir el tiempo de atención a clientes nuevos. Sistema nuevo, proceso rediseñado, formación impartida, proveedor renegociado. Los cuatro terminan; tres en fecha.
Catorce meses después, el tiempo de atención bajó un 9% sobre un objetivo del 50%.
El director de programa había hecho un trabajo impecable de coordinación: dependencias resueltas, riesgos compartidos gestionados, informes puntuales. Lo que no hizo fue preguntar, en el mes seis, si alguien estaba comprobando que los responsables de área usaran el proceso nuevo.
No lo usaban. El proceso viejo seguía disponible, era conocido y nadie lo retiró. Formar a la gente estaba en el alcance del proyecto de formación; retirar la alternativa antigua no estaba en el alcance de nadie.
Ese hueco —entre la capacidad entregada y el cambio de comportamiento— es exactamente el territorio del director de programa. Es lo único que no puede delegar hacia abajo.
Cómo saber si el papel está funcionando
- ¿Puede el director de programa decir, sin consultar, cuál es el beneficio y cómo va?
- ¿Ha pedido alguna vez que un proyecto listo espere, por el bien del conjunto?
- ¿Ha planteado la posibilidad de cancelar algo?
- ¿Su informe habla de beneficios o es la suma de los avances?
- ¿Existe un mapa de beneficios con dueño para cada eslabón, incluido el del cambio de comportamiento?
- ¿La fecha de cierre del programa es posterior a la del último proyecto?
Si la respuesta a la mayoría es no, hay alguien con el título y el puesto está vacante.
Para cerrar
Dirigir un programa no es dirigir muchos proyectos: es responsabilizarse del hueco que queda entre lo que se entrega y lo que cambia. Ese hueco no aparece en ningún cronograma, no lo reporta nadie y es donde se pierde la mayor parte del dinero que las organizaciones invierten en proyectos que salieron bien.
Te leo en los comentarios: ¿has visto un programa donde todos los proyectos cumplieron y el beneficio no apareció? ¿Qué eslabón faltó?
Referencias
- Project Management Institute, The Standard for Program Management.
- Office of Government Commerce, Managing Successful Programmes (MSP), sobre mapas de beneficios.
- Ward, J. y Daniel, E., Benefits Management, sobre la cadena entregable-capacidad-beneficio.
- ISO 21503, orientación sobre dirección de programas.
← Anterior en la serie: Cómo se relacionan proyecto, programa y portafolio cuando comparten la misma gente
Siguiente en la serie: Dirección de portafolios: elegir bien no basta si no puedes ejecutarlo →
Este artículo forma parte de Programas y Portafolios de Proyectos, una serie de 42 artículos. Ver todos los de esta serie · Índice completo por materia.