Performing Earned Schedule Analysis with Project Professional 2013

The Earned Schedule (ES) Technique is an extension of the Earned Value Management (EVM) technique that just last year celebrated its 10th anniversary. Since 2003 it has been attracting new adopters continuously, recognized form the PMI as an emerging practice and included in the second edition of PMI’s EVM Standard.

In 2007 the pioneering macro to perform the Earned Schedule analysis with Microsoft Project was released. Now, the tool has been updated to be used with Project Professional 2013 and can be downloaded here. The old menu has been substituted by a new one located on the ribbon, and called EARNED SCHEDULE.

For more information about the use of the macro please look up this entry.

The third annual Earned Value conference for Europe

Es una gran satisfacción para mí anunciar que la tercera conferencia anual de Análisis del Valor Ganado (AVG) para Europa se celebrará este año en Valencia.

Después de las dos exitosas conferencias celebradas en el CERN (Suiza) en 2009, y en Gante (Bélgica) en 2010, gracias a Rafael Sánchez, director de la ETS Ingeniería de Edificación de la Universitat Politècnica de València, y a Eduardo Bolufer, profesor de dicha escuela, este año se celebrará durante los días 23 y 24 de noviembre en la Universitat Politècnica de València.

Aunque el objeto principal de la conferencia es el AVG, la temática está abierta al resto de áreas en Project Management. En concreto, las áreas de la conferencia de este año son las que muestro al final de esta entrada.

La conferencia consta de dos sesiones en paralelo, una académica y otra profesional. Animo a cualquiera de vosotros que tiene por ahí guardado aquello tan interesante para contar que dé el siguiente paso y presente su propuesta para hablar en la conferencia. O, aunque no tengáis nada listo, simplemente participar.

Por otro lado, si alguna compañía u organización está leyendo esto, también les animo a participar y contar su experiencia en la conferencia ante un público proveniente de toda Europa. Les invito también a patrocinar el evento.

Podéis obtener más información en el sitio Web de la conferencia.

Áreas temáticas de la conferencia:

• Algorithmic design for project scheduling and monitoring
• Methodologies for project monitoring
• Methodologies for project performance measurement
• Methodologies for Earned Value Management
• Integration studies between risk analysis and project monitoring
• Successful cases of project management and monitoring
• Comparative studies of EVM software tools
• Time and cost project monitoring
• Time and cost project buffer management
• Optimal allocation of project management reserves
• Project performance stability studies

Adherencia a la programación y factor P (y 2)

Como continuación de la entrada inmediatamente anterior, finalizaremos con algo inédito que no se contó en la conferencia, al menos con este detalle. En aquella entrada seminal, en la que se abordó por primera vez el tema de la adherencia, también se decía que “para aquellas tareas cuyo progreso real en la figura 2 es menor que el de la figura 3 podríamos identificar limitaciones que impiden su avance, mientras que para aquellas cuyo progreso real en la figura 2 es mayor que el de la figura 3 podríamos identificar la posibilidad de que en un futuro se tenga que rehacer el trabajo hecho”.

Una forma de ver esto con detalle es considerar las figuras 2 y 3 de forma conjunta, como se muestra en la figura siguiente:


Entonces podemos construir la siguiente tabla en la que podemos calcular la diferencia para cada actividad entre su valor ganado (BCWP) en la fecha de reporte (Fecha de Estado) y su valor programado (BCWS) en la fecha en la que debería haberse ganado la programación ganada (Programación Ganada):


Cuando la diferencia es negativa, como en el caso de las tareas 7, 8, 9 y 10, ésta debería ser un indicador de riesgo sobre la posibilidad de existencia de algún impedimento o limitación que dificulta el avance de esas tareas -una señal de humo que debería advertir al jefe de proyecto de investigar con mayor detenimiento para determinar las causas de ese humo-. En caso de no existir ningún impedimento o limitación, la causa podría estar en un rendimiento inadecuado del trabajo que se está realizando, procesos no bien definidos o malas asignaciones de personal.

Cuando la diferencia es positiva, como en el caso de las tareas 6 y 11, ésta debería ser un indicador de que su realización no está sincronizada con la programación, con el consiguiente riesgo de tener que rehacer parte del trabajo que se está realizando. Esto es bastante obvio en la tarea 11 porque algunos de los inputs requeridos podrían estar ausentes al no estar aún finalizada una de sus tareas predecesoras –ver tarea 9-, aunque no lo es tanto en la tarea 6 que, aunque no le falta ningún requerimiento, sigue habiendo una falta de sincronía entre su realización y lo programado. El refrán “lo que va por delante, va adelante” podría no tener ningún tipo de sabiduría en este caso al estar incurriendo en el riesgo de tirar a la basura el trabajo adelantado para volverlo hacer de forma correcta.

En este sentido, la tabla anterior se puede utilizar de filtro que permite focalizar la atención del jefe de proyecto en aquellas actividades que pueden merecer especial atención en un momento dado del proyecto. En este caso cómo de adheridas van a la pogramación original y con qué nivel de sincronización se está realizando el trabajo.

Adherencia a la programación y factor P (1)

Hace ya un tiempo hablé de una de las nuevas posibilidades que nos brinda el concepto de Programación Ganada para profundizar en el conocimiento del rendimiento de un proyecto a partir del curso real que van tomando los acontecimientos. Más recientemente incluí el tema en la primera conferencia oficial sobre la Programación Ganada que se realiza en España, en la sede del capítulo de Valencia del PMI, y cuyo material se puede descargar desde aquí. Como en el anuncio que hice en mi blog del evento prometí que si hablaba de algo inédito para el blog, escribiría sobre ello, pues ala, ya no me puedo escaquear por más tiempo. Podría salvarme de escribir más líneas aduciendo que ya está en la presentación que he citado antes, pero, al ser sólo el soporte a la presentación, no dice mucho sin las palabras del orador –bueno, igual es al revés ;-).

Antes de que prosigáis con lo que viene a continuación, os recomiendo que leáis aquella entrada. De sus figuras 1, 2 y 3 –que reproduzco a continuación-






observamos que, con un cronograma del proyecto y un método de evaluación del valor ganado, podemos conocer en un momento dado del proyecto:

1. la distribución del trabajo que debería haberse realizado para esa fecha,


2. como se ha realizado realmente (mediante la distribución por actividad del Valor Ganado),


3. y como debería haberse realizado en la verdadera fecha en que habría de haberse alcanzado el valor ganado acumulado (Programación Ganada), teniendo en cuenta la distribución programada de trabajo para esa fecha.

La comparación entre 2 y 3 nos da una idea de si la distribución de trabajo realizado es consistente en todo momento con la especificada para ese momento del tiempo, independientemente de si vamos con retraso o adelanto, ¡o incluso según lo programado en el total acumulado! A esa diferencia le podemos llamar adherencia a la programación, aunque nos quedamos sólo en el bautizo, no hubo caramelos. Bueno, pues ha llegado el momento. Una forma de cuantificar esa diferencia es a través de lo que vamos a denominar factor P, que no tiene nada que ver con Star Trek, sino que es el porcentaje del trabajo realizado que se ha realizado de acuerdo con la Programación Ganada. Es decir, toda la porción de valor ganado de la figura 3 que queda a la izquierda de la fecha dada por la Programación Ganada, dividido por todo el trabajo programado hasta la fecha correspondiente a la Programación Ganada (figura 3). Esto se ve mejor gráficamente en la figura 4:


Análiticamente se puede escribir de la siguiente forma:


Y no voy a entrar en más detalles sobre tracas y mascletàs matemáticas. La siguiente figura creo que es mucho más ilustrativa sobre cómo se hace el cálculo:


De donde se desprende que P=55/61=0,9 ó, lo que es lo mismo, que el 90% del trabajo realizado se corresponde con la programación.

P, como cualquier porcentaje, está entre 0 y 1 (0% y 100%). En cualquier momento del proyecto podrá ser menor que 1, pero en el momento en que el proyecto finalice, bien sea en, antes o fuera de plazo, será 1 porque ya se habrá realizado todo el trabajo programado. Es decir, a medida que el proyecto se acerca a su fin, por muy poco adherida a la programación que haya sido la realización previamente, al trabajo realizado no le quedará más remedio que corresponderse con el programado en cada momento, independientemente de que el proyecto vaya con retraso, adelanto o en plazo. Porque el factor P no es un indicador sobre el adelanto o retraso de la programación, como es el SPI(t) de la Programación Ganada, sino un indicador sobre, para un retraso o adelanto dado, si el trabajo realizado se corresponde con el que debería haberse realizado según la programación en ese momento dado –repito, sea con retraso o con adelanto-.

Para finalizar esta introducción al factor P, y para que esto vaya un poco más allá de lo que se contó en la conferencia, profundizaré un poco más en otros aspectos de los que no hablé allí. Pero eso queda para la siguiente entrada, que vendrá en breve.

Calcular la Programación Ganada con MS Project 2007

Por fin, el problema que tenía la macro para calcular la Programación Ganada con la versión 2007 de MS Project ha sido resuelto. Bueno, parcialmente. Podéis descargaros aquí el ejemplo que funciona con MSP 2007. Digo parcialmente porque, en esta nueva versión, debido a los cambios que ha introducido Microsoft en el sistema de menús, en MS Project se han quedado a medias de manera que no es posible, hasta donde he podido llegar a saber, asignar una macro a un menú.

Así pues, estas son las instrucciones para proceder. Ahora, al dejar que la seguridad habilite las macros, la macro ya no se trunca como ocurría antes. Veremos que se crea el menú reportes, pero comprobaremos que no hace nada. Lo que haremos, entonces, es ejecutar la macro de forma manual. Para ello pulsaremos la combinación de teclas Alt+F8 y, en el listado de la ventana que aparece, seleccionaremos con el botón izquierdo del ratón la línea “earned_schedule_msp2007_es.mpp!EVSM”. Eso generará el informe en Excel.

Más información sobre el uso de la macro, aquí.

Charla sobre la Programación Ganada en Valencia

El próximo jueves 19 de febrero a las 19:30 horas, dentro de las Sesiones de Trabajo del Capítulo de Valencia del Project Management Institute, impartiré una ponencia sobre la Programación Ganada bajo el título de

Cómo convertir el Valor Ganado en un reloj del proyecto

La asistencia es gratuita y, como miembro del capítulo, estáis invitados todos aquellos que estéis interesados en una herramienta tan novedosa -y vuestra línea espacio-temporal intersecte o pase cerca de Valencia ese día.

Podéis encontrar más información, incluido el lugar de celebración, en la Web del capítulo.

Programación Ganada: cálculo mediante regresión matemática

Con este título me llega la siguiente contribución a la Programación Ganada de unos compañeros de profesión de Perú:

Programación Ganada
Cálculo mediante regresión matemática

Por Thomas Del Solar Knell y Jorge Mosca Corro
Lima - Perú / Enero 2009

Luego de leer el articulo de Programación Ganada, publicada por Diego Navarro en el blog, no fue muy difícil entender el valioso aporte que este índice brinda al control de proyectos, y consecuentemente generó la curiosidad de cómo calcularlo. La forma más simple de presentar nuestro desarrollo es usando un ejemplo; para ello tomemos como valores de Costo Presupuestado (CP) y de Valor Ganado (VG) la información mostrada en la Tabla No.1. En este ejemplo usamos datos de un proyecto en el que se ha excedido el tiempo programado.


Observando el argumento gráfico de lo que significa la Programación Ganada, se nota que este concepto se podría definir geométricamente como la intersección entre la curva del Costo Presupuestado (CP) y la recta horizontal correspondiente al valor numérico de la curva de Valor Ganado (VG) en el periodo a evaluar, esta intersección da como resultado un punto, cuya coordenada en el eje X es el tiempo en el cual debería haberse alcanzado el Valor Ganado y es lo que llamamos Programación Ganada. Ver Graf. 1.


Según este enfoque, para calcular de una manera sencilla la Programación Ganada, lo que nos restaría sería encontrar la ecuación de la curva del costo presupuestado y evaluarla con el valor ganado. Usualmente, el costo presupuestado es una curva en forma de “S” que relaciona dos magnitudes: el costo y el tiempo. Si observamos la curva cuidadosamente, veremos que presenta una forma curva en los extremos y casi recta en el medio, entonces podemos dividir la curva en tres sectores de tal forma que facilite hacer una regresión de segundo grado para los extremos y una lineal para la zona central. Ver grafico. 2.


Fácilmente con el uso de Microsoft Excel se puede obtener la regresión y las ecuaciones para cada rango de datos, con el objeto de finalmente unirlos y formar la curva completa buscada. Inclusive se podría dividir en más sectores en el caso que la curva que grafica el Costo presupuestado sea más compleja. El objetivo es obtener ecuaciones de fácil solución que representen a la curva del Costo Presupuestado (CP) con la misma precisión con la que fue estimada éste.

En el Graf. 3, se puede observar las diferencias entre los dos conceptos de índices de avance de proyecto, el SPI(c) y PG. El SPI(c) inicialmente decrece hasta llegar al mes 13 aprox., donde comienza a mejorar supuestamente, hasta llegar al valor de 1, mientras la PG indica un atraso y recién se muestra una mejora a partir del mes 25, que corresponde con el comportamiento real del valor ganado del proyecto.


Esperamos que esta sugerencia les ayude a calcular la Programación Ganada. Para cualquier comentario favor no duden en contactarnos:

Thomas Del Solar Knell
Jorge Mosca Corro

La programación, el plazo, los informes, los floreros y sus sufridores

No, no es el título de una película de Peter Greenaway, aunque bastantes proyectos parecen seguir más uno de sus guiones que el previsto –si lo hubiere. Tan sólo que resulta que a veces suele haber confusión entre programación y plazo, sobretodo cuando se utilizan las magnitudes del Valor Ganado. La cosa llega a ser grave cuando la “Schedule Variance” (SV) se traduce como “desviación en plazo” en vez de “desviación en programación”. Pues programación y plazo no son lo mismo: programación es la ordenación lógica (o red) y temporal de las tareas de un proyecto, mientras que plazo es la duración de la secuencia de tareas más larga de todos los recorridos posibles a través de la ordenación lógica. Pero, aunque llamemos “desviación en programación” a SV, ¿no es acaso una medida de la desviación respecto del plazo previsto? En principio, no tiene nada que ver. Lo que mide estrictamente SV son diferencias entre trabajo acumulado hasta un instante dado del proyecto, medido en unidades monetarias –el que se ha realizado menos el que debería haberse realizado según lo presupuestado. Y eso no tiene por qué traducirse directamente en diferencias respecto del plazo previsto del proyecto, como se puede ver en el ejemplo representado en las dos figuras siguientes.


La Figura 1 muestra el trabajo realizado en el instante dado por la línea vertical “Fecha de estado” –relleno rojo de las barras que representan las tareas de la programación o cronograma. La curva de color negra representa la curva S del presupuesto acumulado del proyecto y la curva de color rojo el valor ganado acumulado. Si reprogramamos el trabajo no realizado a partir de la fecha de estado, obtenemos la figura siguiente:


En la Figura 2 vemos que la desviación negativa en programación –hemos realizado menos trabajo del previsto hasta la fecha- no se traduce en una desviación en plazo. Claro, las tareas que van con retraso no están en el camino crítico, mientras que las críticas van según lo previsto; ahí lo tenemos. Obviamente, este es un caso entre diferentes combinaciones posibles, algunas de ellas en las que una desviación de programación se traducirá en una desviación del mismo signo en el plazo. Pero vemos que, en general, no hay una relación directa. Solamente tendríamos una relación directa en el caso particular en el que la red de tareas sea una sola secuencia lineal de tareas; en este caso el trabajo se traduce directamente en plazo.

Vemos que las representaciones gráficas ayudan mucho en estos casos, la semántica la podríamos dejar para los cientifistas -podría parecer que me propaso-, posmodernos y gurús –a veces cuesta incluso distinguirlos entre la tupida verborrea. Pero resulta que también suele ocurrir que la función de estas representaciones gráficas se reduce a ejercer de mero florero en los informes de gestión; algo que queda bonito pero que nadie entiende o quiere entender. Consideremos las dos figuras siguientes, ¿cuál acojona más?



Independientemente de la cercanía a la finalización del proyecto, que podría se un criterio más, tenemos el panorama que se nos presenta por delante. En la Figura 3 tenemos que el presupuesto acumulado tiene poca pendiente, lo que quiere decir que no hay mucho trabajo programado para ese periodo. Teniendo los recursos disponibles, podríamos aprovechar ese “falso llano” para recuperar el trabajo perdido. Sin embargo, en la Figura 4 el presupuesto acumulado tiene bastante pendiente, por lo que se hace más difícil recuperar el trabajo perdido en un momento en el que, ya de por sí, deberíamos estar trabajando como c*br*nes. Los gráficos dicen mucho.

Aristotle on Project Management

Alrededor de unos 2.300 años antes de que se inventara la técnica del valor ganado, Aristóteles bien podría haber sentado las bases de uno de los métodos de medición del valor ganado, cuando dijo aquello de que “el principio es la mitad del todo”. Efectivamente, el método del 50/50 se utiliza para acreditar que una actividad aporta la mitad de su valor una vez se ha iniciado, y la otra mitad una vez ha finalizado. Esto puede ir bien siempre que uno no se quede pensando después de abrir la caja de las herramientas si realmente ya ha logrado la mitad del trabajo propuesto. O mejor aún, ¿tiene algún valor la mitad de algo?, ¿sirve la mitad de un puente para cruzar un río? –si se me apura, mi escepticismo empírico me hace a veces dudar de que el 100% de algo tenga algún valor: ¿sirve ese nuevo y flamante edificio para el fin para el que fue concebido?.

Pero, ¿qué tiene que ver, o mejor dicho, qué no tiene que ver esta máxima aristotélica con los proyectos inmobiliarios? Lo que sea que no tenga que ver, quizás pueda resolver una paradoja burbujeante del postladrillismo. A saber, hablas con amigos metidos en el sector, bien sea inmobiliarias, constructoras, bancos, pintores, fontaneros, chapistas, piseros, ventaneros, tallistas, etc., y ya te dicen que van teniendo menos trabajos, que no hay nuevos contratos, que se tarda en cobrar, o no se cobra, vamos, que ya no es lo que era. Pero uno pasea por cualquier lugar y de deforestación nada, sigue viendo una plantación de grúas que ríete tú de la explosión cámbrica. Claro, luego los que están ahí metidos hasta las cejas te cuentan que, obviamente, un edificio no se hace en cuatro días, que lo que se ve por ahí en construcción se comenzó a construir, o incluso se gestó su anteproyecto, antes del punto de inflexión. Y claro, el principio, ni tan siquiera la mitad, no son ni el todo ni su mitad ni la aceituna de Carpanta. Vamos, que no se lo endiñan ni a Aristóteles.

Hace un par de semanas, alguien en un evento de Dirección de Proyectos decía que su compañía producía y vendía tantas unidades al año, enfatizando el “vendía” por aquello de que el producto alcanza su verdadero valor, ya no materializado, sino cuando lo hemos entregado a un cliente, -¡y aunque vendido a un precio menor del convenido inicialmente!, aunque esto último no se dijo. Precisamente, en “El halcón maltés”, recientemente utilizado para ilustrar otras situaciones, asistimos a una escenificación notable de este hecho. En uno de los momentos de mayor clímax de la película, el detective Sam Spade se dispone a recibir por parte del villano Kasper el pago convenido por la figura del halcón:

SPADE: ¿Está dispuesto a hacer el primer pago y recibir el halcón de mis manos?
KASPER: Bien, en cuanto eso… aquí tiene –le responde entregándole un sobre que Spade abre.
SPADE: ¿Diez mil? Habíamos hablado de mucho más dinero.
KAPSER: Sí, en efecto. Pero esto es dinero de verdad. Con un dólar se puede comprar información por valor de 10.

Lo cuál nos lleva a una conversación que manteníamos algunos en una mesa, durante la comida después del evento. En el momento clímax de aquella conversación, alguien completaba la frase mencionada anteriormente del evento: producimos, vendemos, y cobramos tantas unidades al año.

Cobrar o no cobrar, ahí radica el valor. Lo que cuente el volao ese del blog de Dirección de Proyectos...

Prestigioso reconocimiento para la Programación Ganada

Walt Lipke, el creador de la técnica de la Programación Ganada (Earned Schedule), una extensión del Análisis del Valor Ganado, ha sido galardonado con el PMI Eric Jenett Project Management Excellence Award, que reconoce a quien realiza una contribución destacada a la profesión de la Dirección de Proyectos mediante algún acto que demuestre liderazgo e iniciativa y un avance en los conceptos, técnicas, prácticas o teorías de la Dirección de Proyectos. Es un galardón muy prestigioso, siendo Walt la quinta persona que lo recibe en diez años de existencia.

El premio será entregado el próximo 6 de noviembre, durante la celebración de la decimonovena conferencia internacional de gestión integrada de programas, que se celebra en Washington DC. Congratulations Walt!

Hacer lo que hay que hacer y "cuando" hay que hacerlo

Un plan de proyecto es como ese best-seller de mil quinientas páginas que se está reservando para leer durante las próximas vacaciones bajo el frágil cobijo de una sombrilla abrasada por la canícula, entre aromas de sílice, salitre y caldo de pescado, y refrescado a veces por la brisa marina. Virgen entre sus manos parece una obra maestra; página a página describe el curso que deben tomar los acontecimientos; después de una página viene otra; el orden brilla por doquier. Sin embargo, ejecutar un proyecto ya no es como esa lectura ordenada tumbado en la playa. Ejecutar un proyecto sería algo como arrancar una a una las mil quinientas páginas de su precioso e impoluto best-seller y lanzarlas al aire durante un azote de viento. El efímero lapso de tiempo entre el lanzamiento al aire y la caída en la arena de cada una de las páginas, correspondería a la duración del proyecto y todos sus avatares. Sí, efímero. Si se le antoja más largo, tan sólo se debe a su percepción psicológica del paso del tiempo. Entonces viene la parte emocionante: después de recoger cada una de las páginas, ¿qué posibilidades tiene de leer la historia original? De las 1500! posibles reordenaciones –aquí el signo de exclamación no expresa el asombro por el tocho de best-seller sino el símbolo matemático de factorial- solamente una describe la historia original. Y existen tantas reordenaciones como granos de arena hay debajo de la toalla sobre la que está tumbado, así que sus posibilidades son las mismas que las de encontrar el grano de arena adecuado bajo su toalla, mejor pruebe con la bonoloto.

Pero dejemos de pensar en las próximas vacaciones y volvamos a la realidad cotidiana de nuestra oficina. La divagación anterior no tenía más objetivo que mostrar que Murphy juega con todas las cartas menos una, debe tener una buena manga de donde sacarlas, y el mazo tiene tantas que no hay dedos humanos suficientes en este planeta para poder contarlas ni de lejos. Así que las formas en que hace trastadas en nuestro proyecto son inescrutables. Vamos a considerar un tipo muy particular de sus travesuras, el concerniente al progreso de las actividades. En su conjunto, un proyecto puede ir con retraso, con adelanto o según lo previsto, aunque, como dice Murphy, este último caso es el que suelen reportar los jefes de proyecto que no se enteran de nada. Consideremos el caso, nada del otro mundo, en que va con retraso. Hemos realizado menos trabajo del previsto hasta el momento. ¿Quiere decir eso que todas las actividades van con retraso? Podría ser. Pero también podría darse el caso de que algunas actividades vayan incluso son adelanto, aunque el retraso de las otras tenga más peso y haga que globalmente haya retraso. Observamos que si profundizamos en el asunto hay una riqueza de situaciones subyacente. Y analizándolo podemos encontrarnos con respuestas interesantes, como por ejemplo limitaciones que están impidiendo el progreso de algunas actividades, o detectar que el trabajo adelantado que se está haciendo en otras puede conducir a una situación en la que se tenga que repetir, por lo que mejor arriamos el burro –una cosa es que Murphy nos sorprenda en la esquina y otra que vayamos a buscarle las cosquillas. Este es el tipo de trastadas que vamos a analizar. Precisamente estamos en disposición de hacer esto gracias a la técnica de la Programación Ganada. Veamos cómo.

Consideremos el ejemplo de la figura 1.


Tenemos la red de actividades de un proyecto atravesada por una línea vertical que marca el momento actual del proyecto. El relleno negro de las actividades muestra el trabajo que debería haberse realizado en cada una de las actividades hasta este momento, siempre según la planificación del proyecto. Abajo se representa la curva S correspondiente al trabajo acumulado presupuestado para el proyecto. Esto es la teoría. En la figura 2 se muestra la realidad reportada en el momento actual.


Ahora, en vez del relleno negro, tenemos un relleno rojo que muestra el progreso real de cada una de las actividades según el trabajo reportado hasta este momento. Vemos que hay actividades cuyo progreso es menor del planificado, y una con mayor progreso del que debería, una de las múltiples cartas de Murphy. Esta última actividad ha dado comienzo incluso sin haber finalizado una de sus predecesoras, ¿les resulta familiar? Abajo, aparte del trabajo planificado, aparece ahora la curva S correspondiente al valor ganado que, como es menor del planificado hasta el momento, indica que vamos con retraso. Y ahora sale en escena la Programación Ganada (PG). ¿En que momento del tiempo deberíamos, siempre según lo planificado, haber alcanzado el trabajo que realmente hemos ganado o aportado al proyecto? En la figura 3 lo tenemos.


Lo interesante de esta figura ya no es el retraso en programación dada por la PG, sino cómo debería ser el progreso de cada una de las actividades de acuerdo con el momento en cuestión en que se mide el progreso global del proyecto. Vemos que, para el mismo volumen de trabajo acumulado del proyecto, la distribución de progreso de la figura 3 no tiene nada que ver con la de la figura 2. Hay múltiples formas a su vez de ir con un retraso dado en un proyecto. Murphy tiene la capacidad de desdoblar al azar las cartas que va sacando al azar, vaya; qué tío este Murphy. Llegado este momento, no vendría mal definir un nuevo concepto, el de adherencia a la programación. Este nuevo bicho de nuestro bestiario de la Programación Ganada mide el grado de fidelidad con que seguimos la programación del proyecto. Así pues, una cosa es si vamos adelantados o retrasados en trabajo, y otra muy diferente si, de acuerdo con nuestro nivel de adelanto o retraso, la distribución de trabajo realizado es consistente en todo momento con la especificada para ese momento del tiempo, es decir que el alcance se va completando según lo dispuesto en la programación, de ahí lo de adherencia.

¿Y qué conclusiones se pueden sacar de esta inadherencia a la programación? Pues comparando la distribución de la figura 2, lo realizado, con la de la figura 3, lo que debería haberse realizado según el retraso, y ojo, nunca con la de la figura 1, lo que debería haberse realizado según lo planificado, podemos extraer algunas conclusiones interesantes. Por ejemplo, para aquellas tareas cuyo progreso real en la figura 2 es menor que el de la figura 3 podríamos identificar limitaciones que impiden su avance, mientras que para aquellas cuyo progreso real en la figura 2 es mayor que el de la figura 3 podríamos identificar la posibilidad de que en un futuro se tenga que rehacer el trabajo hecho. Los detalles dependerán de cada proyecto concreto, lo que muestra esta comparación es un punto de partida para focalizarnos en aquellas actividades donde podrían ocurrir estas cosas. Cualquier gestor debería dar su reino por una herramienta de focalización.

La Programación Ganada gana terreno

El pasado 12 de junio se celebró en Bruselas una presentación de la novedosa técnica de la Programación Ganada (Earned Schedule en inglés), organizada por los compañeros del capítulo belga del PMI y patrocinada por Microsoft. Ante una audiencia de 150 personas, Walt Lipke introdujo el concepto de Programación Ganada y habló de las motivaciones que lo hacen necesario, Kym Henderson mostró su poder predictivo mediante análisis de datos provenientes de proyectos reales, y Mario Vanhoucke dio a conocer los resultados de sus investigaciones que muestran que el poder predictivo de los nuevos indicadores introducidos por la Programación Ganada es mayor que el de sus predecesores del Valor Ganado. Este resultado, obtenido mediante simulaciones Montecarlo, viene a respaldar los obtenidos con datos reales que muestran que son al menos tan buenos como los del Valor Ganado. La importancia de esto no es baladí pues, como en toda práctica incipiente, no faltan los detractores, sobretodo cuando la técnica tradicional del Valor Ganado es casi un hecho religioso en los EEUU y cualquier cosa que se pueda apercibir como algo que quita méritos, cuando en realidad no es así, siempre provoca las reacciones de los más integristas. Así pues, la Programación Ganada gana terreno.

Asimismo, Walt anunció al público belga la aparición de la macro que permite realizar algunos de los cálculos de la Programación Ganada con Microsoft Project, que presenté aquí en abril. Espero que dentro de poco aparezca una versión comercial instalable como complemento, con una mayor versatilidad a la hora de efectuar los seguimientos del proyecto, y con la introducción de los últimos desarrollos de la técnica de la Programación Ganada –esto es publicidad de pre-lanzamiento, por tanto. Finalmente, el presidente de capítulo belga entregó a Mario Vanhoucke un cheque de 5.000 € para proseguir sus investigaciones. Puede parecer poco pero, como dijo Mario entre sus palabras de agradecimiento, con lo que en una empresa representa muy poco, en el mundo académico se pueden hacer muchas cosas. Para profundizar en la Programación Ganada, pincha aquí.

Abajo podéis ver a algunos de los protagonistas y a un convidado de piedra.


De derecha a izquierda: Chris Kindermans, presidente del capítulo belga; Walt Lipke, padre de la criatura –es decir, la Programación Ganada; Mario Vanhoucke, profesor de la universidad de Ghent; Stephan Vandevoorde, director de programas del capítulo belga; Kym Henderson, director de formación del capítulo de Sidney; y finalmente la piedra que suscribe estas líneas.

Cómo calcular la Programación Ganada con Microsoft Project

English version

Novedades 16/01/14: Una nueva versión que funciona con Microsoft Project Professional 2013 ya se puede descargar desde aquí.

Novedades 11/03/11: La versión MSP 2007 de la nota anterior también funciona con MSP 2010.

Novedades 27/02/09: Una nueva versión que funciona con MSP 2007 ya se puede descargar desde aquí.

Novedades 14/06/07: la primera versión se ha sustituido por una nueva en la que se ha corregido un error de cálculo.

La técnica de la Programación Ganada (ES de su acrónimo en inglés) es una extensión del Análisis del Valor Ganado (AVG) que ha sido reconocida recientemente como una práctica emergente por el Project Management Institute (PMI). Este enfoque novedoso se basa en el potente concepto de Programación Ganada (PG) introducido por Walt Lipke en su artículo pionero “Schedule is Different”. La razón que dio lugar a esta extensión fue el hecho bien conocido de que, en algunos escenarios concretos, algunos indicadores del AVG, como la desviación en programación SV y el índice de eficiencia en coste SPI, se comportan de forma inesperada a partir de cierto momento hacia el final de un proyecto, perdiendo todo su poder predictivo. Para conocer más sobre esta técnica ver la documentación de dominio público que se encuentra en Earned Schedule. Dado que es una práctica muy reciente, hasta donde sé los principales paquetes de software sobre programación de proyectos aún no la incorporan. El propio Lipke ha puesto a disposición una hoja de cálculo para automatizar el cálculo de la PG partiendo del coste planificado BCWS y del valor ganado BCWP.

Quiero mostrar aquí una macro realizada en VBA para MS Project (MSP) que prepara informes mensuales en Excel de los indicadores del AVG y de la PG con el propósito de que pueda ser útil para proyectos de pequeña y mediana entidad cuya programación se lleva con MSP. Y solamente su programación, es decir que el coste se lleva a parte –práctica nada extraña por otro lado. El tipo de proyecto para el que se utiliza la macro es aquél compuesto por actividades desempeñadas por recursos del tipo de mano de obra, en la que su duración se puede condicionar a su esfuerzo. De esta forma, tanto el coste como su duración son proporcionales al esfuerzo, horas-hombre por ejemplo. De esta manera, con seguir las horas es suficiente. Por mi experiencia, la tipología propia de estos proyectos unida a la inmadurez relativa de las organizaciones que suelen desempeñarlos hacen que efectuar un seguimiento del coste, además de la programación, sea con bastante frecuencia una empresa infructuosa. Otro inconveniente de MSP es que posee una implementación del AVG muy pobre, ya que no permite llevar un seguimiento histórico de las curvas S para los costes BCWS, BCWP, ACWP y sus magnitudes derivadas, y por tanto tampoco permite mostrar una representación gráfica de las mismas. Por otro lado, como adelantaba al principio, no incorpora la PG.

En el siguiente archivo de MSP, versión 2003, se puede encontrar un ejemplo del funcionamiento de la macro. Si el fichero se va a abrir con una versión diferente saldrá un mensaje de error y habrá que seleccionar las librerías adecuadas desde el menú del editor de Visual Basic de MSP: Herramientas-->Preferencias. Estas librerías son "Microsoft Project xx.x Object Library" and "Microsoft Excel xx.x Object Library", donde xx.x es la versión correspondiente a la versión de MSP -11.0 para MSP 2003. No olvidar tampoco comprobar el nivel de seguridad de macros de manera que permita su ejecución. Una vez abierto el archivo, aparecerá un nuevo menú llamado “Reports” en la barra de menús. Pinchando sobre el mismo se obtiene el informe en Excel del proyecto. El archivo contiene un ejemplo de proyecto con una duración de 18 meses que se ha actualizado de forma mensual seis veces desde su inicio. Para que el informe se pueda generar, debe haberse guardado una línea base con la planificación inicial del proyecto, y asignar una fecha de estado adecuada. Cada vez que se genera un informe mensual, el archivo va guardando estos datos de forma que va creando un histórico mensual de los indicadores que aparece actualizado cada vez que se genera el informe en Excel, pudiendo así descartar los informes generados con anterioridad. De esta manera, el informe muestra de forma gráfica la evolución de las curvas S y el resto de indicadores. Las magnitudes de tipo coste están medidas en horas-hombre y las de tiempo en semanas o días.

Corrección de erratas

El pasado 26 de noviembre publicaba un documento sobre el Análisis del Valor Ganado, que unificaba la serie de anuncios que había venido publicando sobre el tema. Entre otras cosas decía que había “tenido que revisar, corregir erratas…”. Bueno, el ingenuo nunca pierde la capacidad de asombro. En este caso sobre cuan paradójicamente perfectos somos a la hora de crear imperfección. Porque resulta que aún había quedado algún error importante. Aquí se puede descargar una nueva versión “corregida”, aunque en el acceso a través del anterior anuncio también se accede ya a esta nueva versión. Gracias Iñaki por la lectura relajada del documento y la detección de las erratas. Las correcciones importantes se han producido en la fórmula (2) de la página 3, y las fórmulas (9) y (10) de la página 11.

Seguimiento de proyectos con el Análisis del Valor Ganado (y 13): epílogo

Llevaba largo tiempo pensando en recoger y unificar bajo un mismo formato todo aquello que he ido contando en esta serie acerca del seguimiento de proyectos con el Análisis del Valor Ganado (AVG). Esta visión se ha visto finalmente materializada en este documento, cuya culminación ha sido más ardua de lo que un refrito de textos podía suponer a priori. Para ello he tenido que revisar, corregir erratas y estilo, además de entrelazar las diversas partes del documento que, pese a provenir de una serie más o menos homogénea, nunca lo puede ser dado el carácter discontinuo y espaciado en el tiempo de los diferentes fragmentos. Releyendo sentía a veces que me hubiera acechado el peligro que narraba Montaigne de que hubiera perdurado el recuerdo de las cosas pasadas habiendo perdido el recuerdo de sus repeticiones. Espero haber salido indemne de él.

Por otro lado, he optado por volver a los orígenes, por lo que a notación se refiere, y reescribir todas las magnitudes del AVG en su versión estándar y tradicional. Al final he añadido un glosario con las definiciones originales en inglés de estas magnitudes y su traducción española. El artículo, al igual que esta serie, finaliza con una introducción a la Programación Ganada (PG), una técnica de muy reciente aparición en la disciplina de la Dirección de Proyectos. Obviamente, se puede profundizar más en PG –al igual que en AVG-, pero he preferido cerrar esta serie –y el artículo- con el alcance que se ha configurado a lo largo de la misma ya que le confiere un todo coherente y un nivel más que suficiente para su aplicación al seguimiento de proyectos. Ello no quiere decir que sigamos ahondando en ello, sólo que con esto cerramos una etapa.

Seguimiento de proyectos con el Análisis del Valor Ganado (12): el concepto de Programación Ganada

En el sexto anuncio de la serie del Análisis del Valor Ganado (AVG), en el que se abordaban los diferentes indicadores para medir la eficiencia de un proyecto, descubrimos que el índice de eficiencia en programación EP -y la desviación en programación DP- presentaban un comportamiento aparentemente anómalo en los últimos estadios del proyecto. En efecto, si rescatamos el historial de desviaciones del ejemplo que se proporcionaba en aquel anuncio, observamos que, mientras la desviación en coste DC sigue una tendencia decreciente a lo largo del proyecto, la desviación en programación invierte esa tendencia a partir de de la semana 20, más o menos.



Parece como si el proyecto se hubiera recuperado en plazo y finalmente hubiera terminado en el plazo previsto, cuando en realidad ha finalizado dos meses más tarde –ver el ejemplo. Algo similar ocurre con las respectivas eficiencias. En realidad, este hecho no es más que una consecuencia de la definición del concepto de valor ganado VG, magnitud que, por construcción, tiene que coincidir con el coste planificado CP del proyecto en el mismo momento de su finalización. Aunque ello no quita para que perdamos el poder informativo de estas magnitudes relacionadas con el plazo. Como anunciamos en su momento, esto constituía una flaqueza del AVG. Afortunadamente no es un escollo que no se pueda solventar.

Hay que resaltar que esta flaqueza no quiere decir para nada que el valor ganado sea un mal concepto. Todo lo contrario. Es uno de los últimos conceptos más importantes que se han aportado a la disciplina de la dirección de proyectos. Sólo el hecho de permitir obtener desviaciones en coste realistas frente a las malas prácticas, aunque muy extendidas, de medirlas respecto al presupuesto inicial, ya es un gran avance en sí mismo. Lo único es que hemos encontrado que tiene sus limitaciones a la hora de tratar la programación. Unas limitaciones que se pueden superar extendiendo el método. Y aquí es donde entra el concepto de Programación Ganada. En realidad, es una idea análoga a la del valor ganado, aunque en vez de utilizar unidades monetarias para medir desviaciones y eficiencias de programación se utilizan unidades de tiempo. El concepto de programación ganada, como todos los que hemos visto del AVG, es extremadamente simple e intuitivo. La programación ganada, que denotaremos por PG, no es más que la fecha en la que el coste planificado acumulado CP del proyecto es igual al valor ganado acumulado VG en la fecha de estado FE. Si el proyecto sigue a rajatabla su curso planificado, estas fechas coincidirán. En caso contrario, no; como se muestra en la figura siguiente:


Es importante resaltar que la introducción de esta nueva magnitud no supone incrementar el número de magnitudes que se miden directamente, ya que se mide a partir de otras. Es una magnitud derivada. Esto es muy bueno porque lo realmente complicado en el AVG es obtener medidas directas. A partir de esta magnitud podemos obtener unas nuevas desviación y eficiencia en programación que sustituyan a las del AVG. En primer lugar definimos la desviación en programación DPt como DPt = PG-FE, mientras que la correspondiente eficiencia como ECt = PG / FE. Y ya está todo. Ahora tan sólo resta determinar cómo se calcula la programación ganada PG. Pero antes hagamos una pequeña reflexión acerca de la interpretación de la desviación en programación DPt, medida en unidades de tiempo –días, semanas, meses, etc. ¿Tiene algo que ver esta desviación con la que me daría un diagrama de Gantt? Si echamos un vistazo a la figura anterior, vemos que la desviación se calcula a partir de la diferencia entre valores acumulados del coste planificado y el valor ganado. Valores acumulados. En cambio, en un diagrama de Gantt, una desviación en plazo de, digamos, una semana se puede deber tanto a que una tarea posee una desviación de una semana como que cinco tareas en paralelo posean todas ellas una desviación de una semana. Aunque la desviación es de una semana en ambos casos, a nadie se le escapa que el segundo caso es más difícil de recuperar que el primero, debido ha que hay más trabajo sin hacer. Esto no es más que una manifestación de la diferencia que hay entre esfuerzo y duración. Pues la desviación en programación dada por la programación ganada refleja precisamente este último caso. Ofrece una idea del tiempo que llevaría recuperar todo el trabajo no realizado hasta la fecha, independientemente de los plazos. Hay que reconocer que el concepto no deja de ser potente. Imagínese que le comunican que lleva un día de retraso en el plazo del proyecto, pero que supone un esfuerzo de dos semanas recuperar ese plazo. Así pues no hay que confundir una desviación en plazo que la obtengo a partir de un diagrama de Gantt, y una desviación en programación –el término más que nada para distinguir- que obtengo a partir del AVG extendido.

Ahora volvamos al asunto de cómo calcular la programación ganada PG. Considerando el ejemplo de la figura anterior, la programación ganada debería tener un valor comprendido entre los meses 5 y 6. Denotemos por x a esta fracción, como se muestra en la siguiente figura:


Las claves para el cálculo los encontramos en el área delimitada por el círculo verde. Y ahora es cuando viene la aproximación –a estas alturas ya deberíamos estar acostumbrados a ello :-). Vamos a considerar que la porción de curva CP comprendida entre los valores CP(5) y CP(6) es recta. Hay dos conclusiones que podemos extraer de esto:

1. Esta asunción se aproximará más a la realidad cuanto más pequeña sea la escala de la dimensión temporal –el eje horizontal; esto es, semanas mejor que meses, mese mejor que trimestres, etc. Pero que no nos ciegue esto; no hay que olvidar que siempre hay un límite en el que el ruido del entorno invalidará cualquier efecto producido por ser más preciso.
   
2. Hay que desconfiar de aquellos que emiten juicios categóricos del tipo “la lógica matemática demuestra que…”. La matemática dirá lo que tenga que decir en su contexto. En el que nos manejamos nosotros sería más conveniente un juicio del tipo “los siguientes resultados ofrecen una desviación bastante aproximada por la razón que…”. La experiencia me dice que cuanto más categórico es un argumento, menor es la idea que tiene sobre el asunto el que argumenta.

Pero continuemos con el cálculo. Si ampliamos la zona rodeada por el círculo verde, tenemos la figura siguiente:


Dado que el triángulo pequeño y el grande están a escala entre ellos, por relaciones de semejanza obtenemos el valor de la fracción x. A saber x = [VG(7) – CP(5)] / [CP(6) – CP(5)]. En general, para una programación ganada PG que se encuentre entre el instante n y el n+1, tendremos que x = [VG(FE) – CP(n)] / [CP(n+1) – CP(n)], con lo que la programación ganada será PG = n + [VG(FE) – CP(n)] / [CP(n+1) – CP(n)]. Y ahora vamos a ver cómo se utiliza esta traca, que así parece más de lo que es. En el ejemplo de la tabla siguiente tenemos que PG = 6 + (4257-4127) / (5122-4127) = 6,1 meses. Así de simple.

Para completar la exposición retomaremos el ejemplo del libro de Excel que se ofrecía en el sexto anuncio. Pero antes los créditos. El concepto de Valor Ganado se debe a Walt Lipke, quien lo presentó en una publicación en marzo de 2003 cuando estaba al cargo de la división de software del Centro de Logística Aérea de Oklahoma. La técnica de análisis ha sido posteriormente desarrollada conjuntamente con Kym Henderson, director de educación del capítulo de Sydney del PMI. Walt Lipke ha desarrollado asimismo un libro de Excel en el que ha automatizado los cálculos de las diferentes magnitudes asociadas a la Programación Ganada. Podéis descargarla desde este sitio en su versión original en inglés o desde aquí en español. Quiero agradecer a Walt Lipke y Kym Henderson el permiso para traducir al español la hoja de cálculo de la Programación Ganada y distribuirla entre la comunidad de habla española.

Vamos ya con el ejemplo. En el siguiente libro de trabajo de Excel se puede encontrar la plantilla del AVG actualizada con la extensión de la programación ganada. A continuación muestro un par de figuras extraídas del ejemplo para comentar las comparaciones entre las antiguas desviación y eficiencia en programación y las nuevas. En la primera figura se muestra el historial de las desviaciones. La figura es la misma que abría este anuncio salvo que ahora se incluye la nueva desviación en programación DPt en color azul –¡ojo ahora medida en meses según la escala vertical de la derecha!


Podemos comprobar que este indicador sí que proporciona buena información hasta el final del proyecto, a diferencia del anterior –en color amarillo. Al final del proyecto, la desviación es de dos mese, justo el retraso que ha tenido el proyecto. También se puede ver como hacia el final del proyecto se hace un esfuerzo para recuperar plazo y que el proyecto no termine con más retraso aún. Como ya dijimos en su momento, esto nos da información de la buena. La siguiente y última figura muestra el historial de eficiencias:


Nuevamente observar las diferencias entre la curva amarilla, la antigua, y la azul, la nueva. La azul es fiable hasta el final.

Seguimiento de proyectos con el Análisis del Valor Ganado (11): midiendo el valor ganado, tercera parte

¿Puede tener una tarea un grado de avance del 120%? Como poder todo depende de lo que queramos entender por grado de avance. Hablando en términos de valor ganado, ¿puede una tarea haber ganado mayor valor que su coste presupuestado? Análogamente al ejemplo anterior, dependerá de lo que entendamos por valor ganado. Según el criterio asumido por al Análisis del Valor Ganado (AVG), las preguntas formuladas anteriormente tendrían la misma respuesta que esta: ¿se puede llenar con litro y medio de agua una botella de un litro?

El grado de avance de una tarea (GA), y en general de un proyecto, debe ser una magnitud cuyo recorrido vaya desde 0% (tarea cuyo inicio aún no se ha acreditado, ojo que esto no significa que no se haya iniciado) a 100% (acreditación de que se han alcanzado sus resultados). De la misma manera, el valor ganado VG de dicha tarea variará entre cero y el coste planificado CP para la misma. Cuando una tarea se da por finalizada, se asume que su grado de avance es del 100% y se ha ganado todo el valor inicialmente presupuestado: VG=CP. Para el modelo sencillo de “grado de avance”, el cálculo del valor ganado es VG=GRxCP. Otra cosa muy distinta es que en un momento dado el grado de avance que, según la planificación, debería ser del 20%, sea del 25%. O que el valor ganado acumulado hasta ese momento sea de 2.500 €, cuando el coste planificado acumulado para el mismo momento es de 2.000 €. Todo ello indica que vamos adelantados en programación. Pero, independientemente de que finalicemos la tarea (o proyecto) con antelación o retraso, nos hayamos gastado más o menos de lo presupuestado, siempre ocurrirá que el grado de avance es del 100% y el valor ganado será igual al coste planificado. No hay ninguna razón extraña y oculta para ello, simplemente se debe a nuestra definición de los conceptos de grado de avance y valor ganado.

Pero resulta que el cableado de fibra óptica de cierta área estaba estimado en 10 días a razón de 500 € diarios (el coste planificado será de CP = 5.000 €), y en cierto momento se nos dice que se han imputado ya 12 días. ¿Qué está ocurriendo? ¿Llevamos un grado de avance del 120%? ¿Un valor ganado de 6.000 €? Obviamente se han invertido dos días más de los inicialmente previstos, pero eso no quiere decir que le hemos cogido gusto a eso de cablear y nos hemos salido del área inicialmente prevista (este caso supondría un cambio en el alcance y sobre ello hablaremos en un futuro). Lo que ha ocurrido en realidad es que vamos con retraso. Vamos a considerar las dos posibles situaciones: (1) que he finalizado en 12 días; (2) que aún no he finalizado. En el primer caso he finalizado en 12 días, por lo que el grado de avance será del 100% y el valor ganado VG=CP = 5.000 €. Ahora bien el coste realizado será de CR = 6.000€. Las desviaciones serán de DC = -1.000 € y DP = 0 € respectivamente.

En el segundo caso aún no he finalizado, aunque ya llevo invertidos dos días más de los inicialmente presupuestados. ¿Cómo calculo el grado de avance? La referencia inicial ya no me vale porque la he sobrepasado, eso me daría un grado de avance irreal del 120%, ¡cuando aún no he finalizado! Realmente necesito una nueva estimación de lo que me resta para finalizar. Bien, llevamos 12 días, ¿cuántos estimamos que nos quedan para finalizar? Supongamos que son 3 días, eso quiere decir que la nueva duración estimada es de 15 días. El grado de avance será entonces de 12/15 = 80%, esto sí que tiene sentido. Y ahora viene el cálculo clave que nos hará comprender en toda su amplitud el concepto de valor ganado. El valor ganado será el 80% del coste inicialmente presupuestado de la tarea, que era de 5.000 €, VG = 4.000 €. Así tenemos que CP = 5.000 € (¡en teoría ya debería haber finalizado!) y CR = 6.000 €. Las desviaciones son DC = -2.000 € (¡y no mil!) y DP = -1.000 € (vamos con retraso).

Para finalizar, una figura que espero que ilustre de forma simple la relación entre los conceptos de coste planificado, valor ganado y modelos de distribuir el coste planificado en el tiempo y medir el valor ganado.


La figura representa un diagrama de Gantt en el que las barras horizontales son las tareas. La línea vertical de color azul representa la fecha de estado del proyecto. El color negro de las barras de tarea representa la planificación, mientras que el rojo representa lo que se ha hecho hasta la fecha representada por la línea azul. El modelo de distribución es el siguiente: cada cuadradito de la rejilla que ocupan las barras de tarea representa un euro. Así pues, el coste planificado acumulado hasta la fecha marcada por la línea azul vendrá dado por la suma de todos los cuadraditos, tanto negros como rojos (notar que en planificación son todos negros) que estén situados a la izquierda de la línea azul. Son 33 cuadraditos: CP = 33 €. Eso es todo lo que se debería haber hecho según lo planificado. El valor ganado es todo lo que se ha hecho hasta la fecha y vendrá dado por la suma de todos los cuadraditos de color rojo, tanto si están a la izquierda como a la derecha de la línea azul. Notar que en algunas tareas puedo ir retrasado y en otras adelantado. Son 29 cuadraditos: VG = 29 €. La desviación en programación es DP = VG – CP = -4 €, el proyecto en su totalidad va con retraso.

Seguimiento de proyectos con el Análisis del Valor Ganado (10): notación y bibliografía

Los lectores que hayan leído sobre el Análisis del Valor Ganado (AVG) y/o lo hayan utilizado, ya habrán notado que la notación que he utilizado referente a las magnitudes que se han ido definiendo no es la que se suele utilizar en la literatura, tanto en textos originales en inglés como en español. En realidad he optado, no sé si con fortuna o no, en definir una nueva notación utilizando tan sólo dos letras que, de alguna manera, hagan de acrónimo del nombre que he dado a las magnitudes. Nombre que, aunque simplificado, si que coincide con las verdaderas magnitudes de siempre del AVG.

En mi opinión, la notación que se ha venido utilizando tampoco es que sea una maravilla, por lo que, dado que la aproximación que he hecho a lo largo de los anuncios de esta serie ha sido, o al menos lo he intentado, de autodescubrimiento progresivo sobre lo que estábamos haciendo en cada momento, me he permitido la licencia de rebautizar los símbolos que representan las diferentes magnitudes, siempre con el fin de reflejar el concepto que representan. Espero que para aquellos lectores que ya están en contacto con el AVG, o que vayan a profundizar los conocimientos adquiridos en otros textos de la literatura, la notación no estándar que he utilizado no constituya un quebradero de cabeza adicional. Con el fin de remediar, o simplemente suavizar, este aspecto, añado una tabla con las equivalencias entre la notación que he utilizado y las más estándares de la literatura o paquetes de software populares.



Finalmente, para quien quiera profundizar en el tema puede hacerlo en los siguientes títulos:

H. Kerzner, Project Management: A Systems Approach to Planning, Scheduling, and Controlling, y Meredith & Mantel, Project Management: a Managerial Approach. Ambos libros cubren de forma general y exhaustiva la Dirección de Proyectos, y del AVG en particular. La notación que utilizan es la tradicional.

J. Davidson Frame, La nueva dirección de proyectos. Este está traducido al español y utiliza una notación muy similar a la de la traducción del MSPoject®.

Por último un par de títulos dedicados exclusivamente al AVG: Q. W. Fleming & J. M. Koppelman, Earned Value Project Management, y PMI, Practice Standard for Earned Value Management. Este último, de reciente publicación, es el estándar oficial del PMI y define su propia notación, aunque no difiere mucho de la tradicional.

Seguimiento de proyectos con el Análisis del Valor Ganado (9): midiendo el valor ganado, segunda parte

La verdad, es que este ha sido el anuncio de la serie que más me ha costado escribir. En todo lo que hemos visto hasta ahora en esta serie sobre el Análisis del Valor Ganado (AVG), dos más dos solían ser cuatro. En lo que viene a partir de ahora, es difícil asegurarlo. Vamos a acabar lo que comenzamos en el anuncio anterior. Vamos a ocuparnos de lo que indistintamente nos hemos referido como modelos de distribución del coste de una tarea o técnicas de medida del valor ganado. Y digo indistintamente porque el modelo que escojamos va a ser la referencia para la posterior medición del valor ganado.

Si tenemos una tarea de dos semanas de duración (10 días laborables) con un coste asociado de 3.500 €, ¿cuándo decimos que se hace efectivo dicho coste? ¿Al inicio de la tarea?, ¿a su finalización? ¿O acaso se reparte uniformemente a razón de 350 € diarios? De esto estamos hablando cuando nos referimos al modelo de distribución. Obviamente, cómo se distribuye ese coste dependerá en gran manera de la propia estructura intrínseca de la tarea, y en menor manera (o mayor, por qué no) de cómo nos interesa que se haga esa distribución. Y me explico. La programación de cierto módulo de software compuesto de dos subsistemas tiene un coste estimado de 1.500 €, de los que aproximadamente mil corresponderían a un subsistema y los restantes quinientos al otro subsistema. Si a su vez hemos estimado el número de líneas de código que contiene cada uno de los subsistemas, podríamos prorratear las cantidades entre el número de líneas de código e ir acreditando posteriormente el coste según vamos teniendo líneas de código; o no acreditar nada hasta que no se ha finalizado cada uno de los módulos; o, más sencillo aún, no acreditar los 1.500 € hasta que no se ha finalizado el módulo entero, después de todo qué significa tener la mitad del módulo si por sí misma no es nada. Y si se me apura, ni tan siquiera el módulo por sí mismo es un producto acabado y lo que realmente tendría valor es la aplicación de software en su totalidad.

Si reunimos a varias personas tendremos opiniones para todos los gustos, y todas ellas justificadas en mayor o menor medida con razonamientos más o menos técnicos, sacados de lo que dicta la experiencia diaria, etc. Los más académicos abogarán por tener en cuenta todos los detalles para alcanzar la máxima precisión posible, porque así los resultados serán precisos, and so on. Los más resabiados nos asegurarán que es una empresa quijotesca y que no hay nada mejor que ir respondiendo sobre la marcha a las inevitables circunstancias del día a día. El lector podrá apreciar que he abierto una caja de Pandora, y mucho me temo que soy incapaz de cerrarla. Es más, me asusta mucho cuando alguien viene diciendo que es capaz de cerrarla, que tiene la solución. Mi conclusión personal es que no existen razones definitivas que justifiquen completamente un modelo concreto en un determinado contexto –algunos compañeros del PMI o defensores a ultranza del PMBOK no estarán de acuerdo conmigo; y no hay nada como la experiencia sensata para matizar lo que se hace en cada momento. Para ilustrar esta opinión consideremos lo que nos dicen los manuales acerca de que cuánto más preciso sea el modelo más exactos son los datos. Bueno, eso puede llegar a ser bastante relativo, por mucho que se lo adorne con adjetivos de exactitud. Cabría preguntarse, ¿y cuan precisa es la estimación de coste de la tarea?, ¿y si en tramos de entro de ella para detallar más? Estamos cómo siempre, ¿dónde empezamos (en pasado) a ser precisos?, ¿cuan preciso se puede llegar a ser? Es cómo esas recetas dietéticas de revista dominical en las que, tras enumerar la lista de ingredientes (un vaso de aceite (qué vasos tiene en casa amigo), dos cucharadas de azúcar (cómo va de pulso), dos o tres unidades de esto o lo de mas allá…), nos indica que su contenido calórico es de 95,6 calorías. Pasmao. “Oiga, que se ha dejado los céntimos en su desviación en coste”. ¡Y el presupuesto del proyecto es de diez millones de euros! Algún día hablaremos de órdenes de magnitud…

En la práctica es muy difícil partir con datos precisos, y no quiero decir que no haya organizaciones capaces de conseguirlo. Lo que sí creo que es una moraleja importante es que, aunque se crea que no se dispone de una precisión exquisita, aún se puede beneficiar uno del uso del AVG; lo que no hay que hacer es ser exquisito donde ya no hace falta, y además va a ser incluso contraproducente. Espero no haber sido muy pesado con estas reflexiones, pero es que las considero clave para comprender el uso de cualquier herramienta analítica. A lo largo de mi vida profesional (y no profesional) me he encontrado tanto con detractores y con suicidas defensores de las mismas que, en última instancia, pretenden justificar cualquier resultado con las mismas. Sin embargo, el terreno que se pisa en estos contextos es bastante movedizo. Cualquier modelo analítico contiene una secuencia lógica de pasos que, una vez asumidos, ya no discutimos; pero el problema no radica ahí, sino con qué fidelidad refleja ese modelo la parcela de realidad que pretendemos explicar con él: ahí es donde hay que ser especialmente cuidadosos y críticos. En el caso del AVG, la secuencia lógica es todo lo que hemos explicado hasta el anterior anuncio; la zona pantanosa se nos presenta con la aproximación del modelo, ahí está el factor limitante. Dicho todo esto, entremos ya de lleno con los modelos más populares, que ya están bautizados.

El modelo más sencillo sea, quizás, el de reparto uniforme, ampliamente conocido en el mundo anglosajón como “nivel de esfuerzo” (LOE de su acrónimo en inglés, el siguiente anuncio lo dedicaré a la bibliografía), y está siendo actualmente popularizado por el PMI. Para una tarea cuyo coste tenga una relación directa con mano de obra, este simple modelo puede reflejar bastante bien la realidad. Sin embargo, si no existe esta relación directa, bien porque la dedicación no es uniforme, o porque se le imputan otro tipo de recursos aparte de la mano de obra directa, la aproximación ya no es tan buena. Precisamente, el PMI recomienda su uso en aquellas tareas que no tienen un resultado tangible y que están caracterizadas por un trabajo realizado a una tasa uniforme a lo largo del periodo de realización de la tarea. Existe otro modelo estrechamente relacionado con éste que, por su denominación, puede crear confusión. Me refiero al “apportioned effort”, que literalmente se puede traducir por esfuerzo repartido o prorrateado, término este último que han escogido los compañeros que han traducido el PMBOK al español. El término prorrateado nos puede inducir a pensar que es el mismo que el anterior, aunque realmente se refiere a tareas cuyo trabajo está ligado a otras, como auditorías y controles de calidad, revisión de material de aprovisionamiento, etc., y en las que su grado de avance está ligado al grado de avance de la tarea a la que da soporte. Estos modelos, consistentes en distribuir de forma más o menos continua el coste de una tarea a lo largo de su duración, se pueden complicar (y de hecho así lo hacen algunos paquetes recientes de software) para intentar reflejar con mayor precisión la realidad: ¿por qué ese reparto tiene que ser uniforme y no en forma de campana de Gauss para reflejar que el mayor esfuerzo se concentra en la zona central? ¿Por qué no varios picos porque el trabajo se hace así? La matemáticas metidas sin ton ni son en un paquete de software por gente que nunca ha dirigido un proyecto, y tan sólo se ha limitado a leerse una manual de métodos cuantitativos y aplicarlo al pie de la letra, conducen a estas cosas absurdas. Una cucharada de aceite tiene 5,17392 calorías, oiga.

Los dos modelos anteriores tienen en común el hecho de distribuir uniformemente el coste. El resto de métodos que vamos a abordar lo hacen de forma discreta. Es el caso del ejemplo anterior en el que acreditábamos el coste al final de la tarea, pero se puede acreditar un porcentaje al inicio de la tarea y el restante al final. Ejemplos son 0/100 (acreditar todo el coste al finalizar la tarea), 50/50 (mitad y mitad), 25/75 (el 25% al inicio y el 75% a la finalización), y cualquier otra combinación. El PMI llama a este modelo “fórmula fija”. El modelo se puede generalizar con la inclusión de varios hitos a lo largo de la tarea en los que acreditar coste. Por ejemplo dos hitos más, aparte del inicio y fina de la tarea, y acreditar un 15%, 35%, 35% y 15% del coste respectivamente. El PMI lo llama “hitos promediados”. Estos modelos son más apropiados para tareas que tiene un resultado tangible (o resultados intermedios tangibles) a los que se puede asociar la acreditación de coste. El último modelo de estas características es el de medir el porcentaje completado de la tarea, en este caso el valor ganado es el resultado de multiplicar dicho porcentaje por el coste total planificado de la tarea en cuestión. Este puede que sea el más sencillo de todos, incluso más que el LOE, aunque arrastrará la subjetividad con que se ha medido el grado de avance de la tarea.

Al final, de lo que se trata es de escoger aquél que se considere más adecuado para cada contexto, y que seamos también capaces de utilizar. Ante la duda o la falta de medios para la recolección de datos, lo mejor es utilizar modelos simples como el LOE o porcentaje completado. Cuanto mayor sea el presupuesto del proyecto, en mayor medida se diluirá su inexatitud. Después de todo, las posibles inexatitudes se darán en aquellas tareas que están en curso, porque en aquellas que ya hayan finalizado ya se habrá acreditado todo el valor ganado. Y tampoco habrá muchas tareas en curso en un momento dado. Qué puedo tener, ¿un error de mil euros en una desviación de 60.000 € cuando ya se llevan ejecutados tres millones y medio de euros sobre un presupuesto total de seis millones? Apretemos más, ¿un error de 10.000 €? ¿Realmente merece la pena ser más preciso? Y ojo, que ese error se debería al hecho de haber considerado una distribución uniforme en vez de una con cuatro picos acampanados, o con haber contado unos centimillos más por aquí, por poner un par de ejemplos. Estas son situaciones que he podido constatar personalmente. En proyectos de estas magnitudes se puede ser bastante generoso en el uso del AVG y, lo que es importante, se puede obtener muy buena información al orden de magnitud correspondiente, que un euro no le quite el sueño, amigo.

Finalmente, por lo que respecta a proyectos de pequeña entidad sí que hay que cuidar un poco más las mangas. Aunque también hay que estudiar si merece la pena realmente aplicar el AVG. En este sentido estoy trabajando actualmente con un compañero de profesión en la aplicación de versiones simplificadas del AVG a este tipo de proyectos y, sobretodo, a situaciones en las que se dispone de poca metodología a la hora de recabar datos. Son métodos que a los ortodoxos podrían escandalizar, aunque a los que vivimos en las trincheras hay cosas que hace tiempo que dejaron de escandalizarnos.

Sobre la serie del Valor Ganado

Quiero agradecer las contribuciones que están realizando algunos lectores y, sobretodo, a aquellos con quienes mantengo conversación a través del correo electrónico. Como todo en la vida, son las matizaciones particulares (la naturaleza del proyecto o el tipo de negocio en este caso) las que de alguna manera acaban por hacer realidad una técnica que deja así de ser una abstracción. La cultura de una organización es un aspecto crucial a la hora de tener éxito en un proyecto, aunque pensemos que siempre puede ser mejorable. En este sentido es muy importante que las técnicas se traduzcan al lenguaje de la organización, que den soporte a sus formas de hacer y no al revés. En definitiva, como meros medios que son, que se le den el uso correspondiente según lo que se espera obtener de ellos.