nodos en la Red

Project Portfolio Management [y 3]

user

Mario López de Ávila Muñoz

Emprendedor e inversor, mentor, advisor. Profesor asociado del área de Operations and Quantitative Methods de la IE Business School, imparte clases en la escuela desde el año 1996. Fundador de la Agile Entrepreneurship Spain, la comunidad hispano hablante de interesados en las metodologías Lean Startup en Meetup decana en España y una de las más grandes del mundo. Startup NEXT Madrid Lead Facilitator. Lean Startup Machine Madrid Co-founder. Co-director del proyecto España Lean Startup. Co-fundador de UEIA, primera aceleradora de empresas sociales de base tecnológica en el mundo.


LATEST POSTS

Let’s talk about Profit Models [I]: introducing Wei-Zhu Profit Model Matrix 06th April, 2015

#LEAN ELEPHANTS True Lean Intrapreneurs 23rd July, 2014

Project Management

Project Portfolio Management [y 3]

el .

Más vale tarde que nunca, o eso dicen.  Ahora que mi rubia – guapa! – tiene claro que esto del Project Portfolio Management (PPM) tiene todo el sentido del mundo – no es fácil manejar casi medio centenar de proyectos simultáneamente sin que se te mueva un pelo, eh? – y aprovechando que estoy actualizando los materiales para las sesiones del IE, voy a rematar la trilogía con unas breves notas sobre la gestión del portafolio de proyectos según TOC.  Es decir, según Critical Chain Project Management (CCPM).

Antes de empezar, me cubriré las espaldas de múltiples maneras.  En primer lugar, amigos míos, no tengo tiempo para escribir un tratado sobre CCPM.  Si queréis saber de verdad del tema, permitidme que os recomiende algunas lecturas que os servirán de gran ayuda.  En segundo lugar, recordaros que sólo soy un practitioner en lo que a Critical Chain se refiere.  Si hay un especialista en la solución TOC para Project Management en nuestro país, ese es sin duda Manuel Rodríguez de TOC Results.  Si queréis plantearos una implantación a gran escala, contactad con él.  Por último – pero no por ello menos importante -, lo que encontraréis, tanto aquí como en la bibliografía disponible, es una solución genérica.  Como expresó maravillosamente Laurence Wright, de la lista de correos CriticalChain en Yahoo Groups,

I am beginning to think that successfully proposing CCPM as a solution has
to be done within the context of each organization’s unique CRT.

Es decir: no basta con seguir la receta al pie de la letra, porque cada organización es un mundo.

Bueno, este "disclaimer" va a ser más largo que el resto del post!

Ppm
Recordaréis que la razón para adoptar prácticas normalizadas, bien gestionadas, de Project Portfolio Management en vuestras organizaciones es garantizar que se está trabajando en los proyectos "correctos" – es decir, en aquellos que mejor desarrollan la estrategia, que resultan más deseables desde un punto de vista económico y que, en conjunto, forman un todo coherente y equilibrado.  El PPM no se ocupa, por otro lado, de la gestión ‘en sí’ de los programas o proyectos individuales en marcha, en un momento dado, en vuestras organizacionesLa preocupación del PPM es garantizar que los recursos disponibles, siempre escasos, se emplean en aquellos proyectos que mayor beneficio aportarán a la organización… llevarlos a buen puerto es otra cosa!  De esto se ocupan "sub"disciplinas del project management como la gestión multiproyecto o el program management.

Critical Chain Project Management, la solución archiconocida de TOC para la gestión de proyectos, fue presentada por Eli Goldratt en su libro ‘Cadena Crítica’ en abril de 1997 – es, pues, una metodología muy reciente – pensad que PERT o CPM datan de los años 50.  A pesar de su ‘juventud’, Critical Chain ha generado toneladas de literatura, la mayor parte de ella para cantar las alabanzas de un acercamiento a la gestión de proyectos que es sin duda el más efectivo de los aparecidos en los últimos 60 años.  Si no estáis usando CCPM estáis perdiendo pasta.  Así de fácil.

La mayor parte de la información disponible hace referencia a lo que se llama la solución monoproyecto de Critical Chain, pero de unos años a esta parte puede encontrarse también algo de material referente a la aplicación de CCPM en entornos multiproyecto.  El primero en hablar de esto con seriedad fue Tony Rizzo – gurú! – en los tiempos en los que Lucent Technologies le pagaba por ser TOCguy, el chico TOC.  Más recientemente, Larry Leach se ha construido una merecida reputación con su magnífico libro de introducción a Cadena Crítica.  Con motivo de la publicación de su segunda edición en 2005, revisó y amplió el capítulo correspondiente al empleo de CCPM para planificar y controlar más de un proyecto.  Ahora bien, esto no es, como ya he dicho, gestión de portafolio de proyectos.  Por decirlo de alguna manera, PPM es lo que va justo ANTES de eso.  Y ¿Qué tiene que decir CCPM sobre PPM?  Pues también aporta algo, aunque lo cierto es que es un ámbito en el que se ha empezado a trabajar hace relativamente poco, a pesar de que ya en el último capítulo de Critical Chain, Goldratt se desmarcase con una nueva métrica – "flush" – cuya intención es ayudar a seleccionar los proyectos que deberían acometerse en una organización  [dicho sea de paso, parece que esta ha sido una de las pocas cagadas del Genio].

CCPM aporta conceptos y técnicas para afrontar la selección de proyectos, el establecimiento de la secuencia de "entrada en fábrica" de dichos proyectos – lo que los angloparlantes llaman el pipelining – y para la gestión en sí del portafolio, especialmente a la hora de contestar dos preguntas críticas: ¿cuándo terminan estos proyectos?; ¿cuánto nos va a costar?  La mala noticia es que tratar todos estos temas en profundidad supera con mucho el tiempo y el espacio disponibles.  La buena noticia es que volveré para desarrollar algunos más adelante.

El primer paso en la PPM es identificar los proyectos.  En esto TOC no os puede ayudar gran cosa… y ya he dicho en otras ocasiones que a menudo es más fácil de decir que de hacer.  En el inventario, suelo recoger toda la información que me ayude a caracterizar ese proyecto: presupuesto, situación, gerente, equipo, compromisos, cliente, etc.  Por introducir un poco de orden, a veces empleo una matriz 2×2 en la
que distingo, por un lado, entre proyectos internos frente a externos y, por otro lado, entre proyectos
"con compromiso de fecha" – obligaciones con clientes, legales, compromisos con la Dirección al más alto nivel, etc – frente a proyectos "a terminar tan pronto
como sea posible" – el resto, claro!!.  También uso otros "diagramas de burbujas", más que nada por deformación de consultor.  Una vez realizado un inventario de proyectos en curso – y, a ser posible, después de hacer una buena limpieza en el mismo – podemos pasar a establecer prioridades en el portafolio.

A la hora de "priorizar" proyectos, la mayor parte de los TOC practitioners usamos sistemas paralelos a los más tradicionales de calificación o ranking.  Se distinguen tan sólo en dos aspectos: en el énfasis que se hace en la incertidumbre o el riesgo asociados al desarrollo del proyecto y en el empleo de tres medidas económicas que son exclusivas de TOC: Throughput – definida como la tasa a la que el sistema genera dinero a través de las ventas, normalmente se calcula como la diferencia entre los ingresos y los costes variables totales; Inventario, definido como el dinero que el sistema invierte en ‘cosas que pretende vender’; Gastos Operativos, por último, es el dinero que el sistema gasta en convertir el Inventario en Throughtput.  La consigna en todo momento es dar prioridad al aumento de Throughput, en segundo lugar a la disminución de Inventario y, en último lugar, a la disminución de los Gastos Operativos.

Para que nos entendamos, podríamos decir que

   Retorno sobre Inversión (ROI) = (Probable variación de T – Prob. Var. de OE) / (Prob. Var. de I)

así que podríamos determinar el "valor" de un proyecto de esta manera

                                                        ROIr = ROI * (1-r)

siendo r un factor de "riesgo", de 0 a 1, que se calcula para cada proyecto [si alguien quiere detalles sobre cómo calcular r, que lo pregunte].  También es cierto que lo normal en estos casos es utilizar el Valor Actual Neto.  Tiene la ventaja de que todos los financieros lo conocen.

Ahora bien, donde TOC nos aporta algo nuevo en relación a la ‘priorización’ de proyectos es al hacernos comprender que esta prioridad no depende tan sólo del valor intrínseco del proyecto, sino que también depende del tiempo que consuman del recurso limitante en la organización.  Si este ‘recurso’ es el departamento de ingeniería,  por poner un ejemplo, los proyectos que generen más valor por unidad de tiempo de uso del recurso limitante tendrán prioridad sobre los demás.  Podríamos expresarlo así

                               Prioridad = Throughput / Trl (Tiempo en el recurso limitante)

En algún caso hemos utilizado VAN o ROIr para seleccionar proyectos – es decir, para "limpiar" el inventario, por ejemplo por el sistema de eliminar todos los proyectos con menos de n euros de VAN – y después hemos ordenado por T/Trl.  Personalmente es la opción que más me gusta.

Para terminar, el cronograma del portafolio de proyectos se establece en función de la agenda del  recurso limitante y luego se traslada a los proyectos individuales, intentando mantener la duración de estos tan corta como sea posible.  La idea es que vas introduciendo en "fábrica" los proyectos por orden de prioridad Y AL RITMO QUE PUEDE MANEJAR EL RECURSO LIMITANTE, que denominamos el "drum", el tambor.  Vamos dando entrada a los nuevos proyectos de forma que el recurso que determina el máximo de Throughput que puede generar el sistema por unidad de tiempo – otra definición de ‘recurso limitante’ – esté siempre A TOPE.

Para que este sistema funcione correctamente, se tienen que cumplir varios requisitos, entre los cuales está el que todos los proyectos individuales se programen utilizando los algoritmos de Critical Chain, para determinar en qué momento – en tiempo relativo – necesitarán del recurso limitante.  Además, como en el caso de los proyectos individuales, es necesario incluir una protección – denominada en este caso Capacity-Constraint Buffer (CCB)para asegurar que el recurso limitante está disponible cuando se necesita para cada proyecto.  Conceptualmente, lo sitúas entre el último instante de uso del recurso limitante por un proyecto y el primer instante de uso del proyecto siguiente.  En la práctica, calcular el tamaño del CCB puede ser un infierno.  Me temo que no puedo extenderme más en este momento.

La agradable sorpresa es que a menudo puedes incorporar más proyectos de los que crees que tu organización es capaz de manejar, siempre y cuando dichos proyectos no consuman tiempo del recurso limitante.  Quedaos con eso, ¿vale?.

profile

Mario López de Ávila Muñoz

Emprendedor e inversor, mentor, advisor. Profesor asociado del área de Operations and Quantitative Methods de la IE Business School, imparte clases en la escuela desde el año 1996. Fundador de la Agile Entrepreneurship Spain, la comunidad hispano hablante de interesados en las metodologías Lean Startup en Meetup decana en España y una de las más grandes del mundo. Startup NEXT Madrid Lead Facilitator. Lean Startup Machine Madrid Co-founder. Co-director del proyecto España Lean Startup. Co-fundador de UEIA, primera aceleradora de empresas sociales de base tecnológica en el mundo.

  • Y tanto ;-)

  • Tu rubia

    Muchas gracias por la explicación, se que lo haces de corazón, pero mis casi 50 proyectos abiertos no me han permitido poder terminar de leer tu post.
    Se que me entiendes ;-)

View Comments (2) ...