Seguimiento de proyectos con el An alisis del Valor Ganado

Diego Navarro
http://direccion-proyectos.blogspot.com/ dnavarro@armell.com

El m etodo del An alisis del Valor Ganado (AVG) es una t ecnica extremadamente sencilla, a pesar de la sensaci on diametralmente opuesta que puede provocar la reciente explosi on en la literatura de t tulos aparentemente sotiscados dedicados al tema, as como el poco uso pr actico que se le da en nuestro pa s. Para rellenar este vac o, el prop osito de este art culo es intentar demostrar cuan sencilla es su aplicaci on y ofrecer unas claves para un uso correcto y, sobretodo, adecuado.

As pues, adem as de los conceptos anteriores de coste real (antes nos hemos referido como gasto) y coste presupuestado, debemos a nadir el coste presupuestado del trabajo realizado (com unmente valor ganado). Estos tres conceptos son los tres pilares fundamentales sobre los que descansa el AVG. El resto, que abordamos de aqu en adelante, no son m as que consecuencias inmediatas de manipular de una forma extremadamente sencilla estos tres conceptos.

I. EL POR QUE

II. CURVAS S

Vamos a comenzar interrog andonos por su motivaci on. Consideremos que en cierto momento de la ejecuci on de un proyecto reunimos informaci on sobre todos los gastos producidos hasta ese momento. Entre estos gastos se encuentran los costes de la mano de obra asignada al proyecto, seg un sus horas imputadas al proyecto; pedidos efectuados a proveedores y otros conceptos derivados de la subcontrataci on; gastos derivados del uso de infraestructuras como alquileres, recibos de luz, etc.; gastos por dietas y desplazamientos; gastos nancieros; y otros m as no citados en esta lista. En denitiva, cualquier salida de la tesorer a de la organizaci on imputable al proyecto en cuesti on. Pues bien, supongamos que esta cantidad asciende a 800.000 C. Ahora consideremos que tenemos un plan de proyecto m as o menos en condiciones, con una predicci on de la programaci on del trabajo a realizar (esto es, las tareas a realizar con su duraci on estimada y calendario de ejecuci on) y un presupuesto elaborado a partir de la proyecci on de costes a lo largo del proyecto. Con todo esto supongamos que, a la fecha en que hemos recabado la informaci on sobre gastos, el coste presupuestado acumulado hasta esa fecha es de 750.000 C. Todo indica que llevamos gastados 50.000 C de m as. Pero, es correcta esta armaci on? En este peque no y r apido an alisis monetario nos hemos dejado otro aspecto fundamental del proyecto: su plazo. Para ser m as precisos, cabr a preguntarse: hemos realizado todo el trabajo programado hasta la fecha? Porque si no es as , si es menos trabajo, la desviaci on en coste deber a ser mayor que los cincuenta mil debido a que tendr amos que haber gastado menos dinero del presupuestado a causa del retraso. En cambio, si se ha realizado m as trabajo del inicialmente presupuestado, igual resulta que los cincuenta mil extra indican, m as que una desviaci on en coste, que hemos adelantado trabajo. Esto es, podr a no haber tal desviaci on o podr a ser menor. Con las preguntas anteriores hemos llegado a la clave central del AVG. Para poder aproximarnos al estado real de un proyecto debemos tener en cuenta tanto los gastos producidos como el avance real de la programaci on temporal. El AVG hace precisamente eso, y nada m as. 1

Una vez vistas las motivaciones, y antes de pasar al c omo, efectuaremos una peque na parada en el camino para ver qu e alforjas debemos preparar antes de embarcarnos en el viaje a trav es del sendero del AVG. El primer ingrediente que necesitamos, y el m as fundamental de todos, es disponer de un presupuesto desglosado a trav es de todas las actividades en que hemos estructurado el proyecto, y distribuido en el tiempo. Esta proyecci on temporal se obtiene en base a dos acciones b asicas: 1. se ha efectuado una programaci on de todas las actividades del proyecto (diagrama de Gantt o similar), 2. se ha establecido un criterio para distribuir temporalmente el coste de cada una de las tareas. ltimo seg Existen m ultiples maneras de hacer esto u un la situaci on concreta ante la que nos encontremos: trabajo efectuado por mano de obra directa o subcontratada; actividades de aprovisionamiento; distribuci on lineal a lo largo de la duraci on de la tarea o discreta en momentos puntuales; otras distribuciones m as o menos variopintas, curiosas, y hasta ex oticas, que nos ofrecen los paquetes de software; etc. En estos casos lo mejor es aplicar un sentido com un entrenado y, ante todo, pecar m as de simplicidad en el modelo aplicado que de lo contrario [1]. ltima advertencia pudiera parecer gratuita, pero no lo Esta u es. Parece mentira observar c omo se puede pasar de no llevar absolutamente ning un tipo de gesti on cuantitativa en un sta proyecto a intentar llevarla y, entonces, demandar que e sea de una precisi on exquisita. Bueno, los t picos movimientos pendulares del ser humano. Esto se suele dar entre gente poco entrenada o, aunque lo est e, con poca capacidad de abstracci on, inducci on y falta de esp ritu cr tico. Hay que tener presente que a partir de cierto nivel de precisi on la realidad no va a coincidir con nuestra planicaci on, por mucho que nos esforcemos en lo contrario [1]. En denitiva, lo que conseguimos con esto es disponer, para una fecha dada de nuestro

proyecto, de un coste planicado acumulado del proyecto, que es la suma de las siguientes contribuciones: Todas aquellas tareas cuya nalizaci on planicada se haya dado en una fecha anterior a la fecha de estado dada, contribuir an con todo su coste planicado al coste planicado acumulado del proyecto. Todas aquellas tareas cuyo inicio planicado ocurra en una fecha posterior a la fecha de estado dada, no contribuir an a un al coste planicado acumulado del proyecto. Todas aquellas tareas que deber an estar en curso en la fecha de estado dada contribuir an con su fracci on de coste planicado seg un el modelo de distribuci on que se haya aplicado. En otras palabras, tenemos la proyecci on temporal del presupuesto del proyecto de la que habl abamos al principio. Representado gr acamente, se obtiene algo parecido a la gura siguiente:

t erminos de plazo. De ah la insistencia en que el desglose no deb a limitarse a las tareas en que se hab a estructurado el proyecto, sino tambi en a lo largo del tiempo. Todo sistema de medida requiere de unas magnitudes cuantitativas y unas unidades. En nuestro caso son el coste presupuestado, el real y el valor ganado, respectivamente, medidos en una unidad monetaria. Dado que lo que pretendemos obtener son desviaciones respecto a un plan original, el coste presupuestado va a ser esa referencia, de manera que va a ser jado en el momento de realizar la planicaci on detallada. Una vez la ejecuci on del proyecto se vaya abriendo paso, se proceder a a realizar medidas de forma regular a lo largo de todo el proyecto de las dos magnitudes restantes: el coste real y el valor ganado. Y eso es toda la iniciativa que hay que llevar hasta el nal del proyecto, el an alisis es totalmente autom atico. Dicho de esta manera, la cosa parece bastante simple. Pero no lo es para nada. El ser humano es capaz de desentra nar las aparentemente complejas leyes que rigen la naturaleza, dise nar y ejecutar complicados procesos de ingenier a, idear y aprender t ecnicas sutiles para resolver problemas diversos no menos sutiles, etc. Y todo ello por muy complicadas que sean. Una vez asimiladas ya no hay secretos. Sin embargo, lo dif cil que puede llegar a ser tener xito a la hora de persuadir a un equipo para que se entregue e a un proyecto, conseguir que los proveedores entreguen los materiales a tiempo, o que el cliente no exceda el alcance establecido; a pesar de que no requieran del aprendizaje de f ormulas complicadas, sino todo lo contrario. A la hora de obtener datos sobre costes reales y valores ganados ocurre lo mismo. Quiz as el coste real (ver la secci on I) sea algo m as sencillo de determinar, si dejamos al margen doble contabilidad, intereses ocultos o acciones fraudulentas. Por lo que respecta al valor ganado, el proceso se torna m as dif cil. El valor ganado es una magnitud crucial para nuestro an alisis, no en balde de ah recibe su nombre el AVG. En sensu stricto no es m as que el coste presupuestado del trabajo realizado, una foto instant anea del progreso del trabajo en un momento dado del proyecto, valorado seg un el coste presupuestado. Si el progreso del trabajo de una actividad coincide con el inicialmente previsto, el valor ganado coincidir a con su coste planicado. La suma de todas las contribuciones de todas las tareas nalizadas o en curso en el momento de tomar la instant anea, nos dar a el valor acumulado para cada una de las magnitudes mencionadas. Si ambos valores coinciden, podemos concluir que el proyecto marcha seg un el plazo previsto; en caso contrario indicar a que marcha adelantado o atrasado. Podemos denir una magnitud para medir esta desviaci on de la siguiente manera SV = BCW P BCW S , (1)

FIG. 1. Presupuesto y curva S

La curva de color rojo, que representa el coste acumulado del proyecto, se suele llamar curva S debido a su forma caracter stica parecida a la letra S. Se observa un crecimiento lento al principio del proyecto, un crecimiento exponencial en las fases intermedias, y una nueva ralentizaci on hacia el nal cuando ya estamos pr oximos a agotar todo el presupuesto. Esta curva es muy propia de fen omenos autolimitados como el consumo de un presupuesto, el crecimiento de la poblaci on de cierta especie de un ecosistema, o el n umero de nuevos edicios construidos en el litoral mediterr aneo -por citar un ejemplo de rabiosa actualidad en el momento en que este art culo ve la luz.
III. EL COMO

Si en la secci on anterior se hac a especial hincapi e en el presupuesto desglosado y proyectado en el tiempo, como un requisito necesario para poder abordar el an alisis, era porque precisamente va a constituir el marco de referencia respecto del cu al se va a medir el rendimiento del proyecto. Y no pensemos solamente en t erminos monetarios, sino tambi en en 2

donde BCW P es el valor ganado, BCW S el coste planicado y SV , al que llamaremos desviaci on en programaci on, nos da una medida de la desviaci on en plazo, aunque en

unidades monetarias1 . Si SV es una cantidad negativa, quiere decir que el valor ganado ha sido menor que el coste planicado o, en otras palabras, que deber amos haber gastado menos dinero del inicialmente presupuestado debido a que vamos con retraso. Si es una cantidad positiva quiere decir que vamos adelantados en programaci on, por lo que tendr amos que haber gastado m as dinero del inicialmente presupuestado. El valor ganado nos da una medida de lo que deber amos haber gastado dado el progreso del trabajo, valorado seg un el coste presupuestado. Eso no quiere decir que nos hayamos ltimo valor lo da el coste gastado realmente ese dinero. Este u realizado que, como su nombre indica, no es m as que el dinero que ha salido de la caja del proyecto hasta el momento. Con todo esto surge, nuevamente de forma natural, una segunda magnitud para medir la desviaci on en coste del proyecto CV = BCW P ACW P , (2)

y coste. La cosa no acaba aqu . Adem as, podemos derivar nuevas magnitudes que permiten efectuar una predicci on acerca de cu al podr a ser el coste al nal del proyecto si las cosas continuaran seg un la tendencia actual.
IV. PREDICCIONES

donde ACW P es el coste realizado y CV la desviaci on en coste. Si la desviaci on en coste es negativa quiere decir que estamos gastando m as que lo que deber amos, mientras que si es positiva todo lo contrario. De la misma manera que existen diferentes formas de distribuir temporalmente el coste de una tarea, se da el caso para dar cuenta del progreso del trabajo invertido en la misma. Tan s olo remitirnos a lo que se dec a en la secci on II: sentido com un entrenado y, ante todo, pecar m as de simplicidad en el modelo aplicado que de lo contrario (ver secci on VIII para m as detalle). Una vez determinado el progreso, el valor ganado se obtiene multiplic andolo por el coste planicado de la tarea (ver secci on VIII). En la representaci on gr aca mediante curvas S tenemos lo siguiente:

Las dos magnitudes (1), (2) derivadas en la secci on anterior nos dan la desviaci on en coste y la desviaci on en programaci on, CV y SV respectivamente, en la fecha de estado en la que se mide el curso del proyecto. Si el trabajo que queda por acometer, con independencia de c omo quede afectado por las desviaciones en que se ha incurrido hasta el momento, se realizara seg un el esfuerzo inicialmente previsto, el proyecto nalizar a con las desviaciones citadas. Pero, a un siendo un pron ostico pesimista (en el caso de desviaciones negativas), quiz as sea mucho m as optimista de lo que creemos. Qu e ocurrir a si esta tendencia de desviarse del plan previsto contin ua a lo largo de todo el proyecto?; sobretodo si no se hace nada por remediarlo. Aqu es donde entramos en el segundo grupo de magnitudes derivadas del AVG (el primero estaba constituido por las desviaciones en coste y programaci on). Como se adelantaba en la secci on anterior, una de estas nuevas magnitudes permite efectuar una predicci on acerca cu al podr a ser el coste al nal del proyecto, si las cosas continuaran seg un la tendencia actual. C omo construir esta nueva magnitud? Pues mediante la cuenta de la vieja. Pero, antes de contar, vamos a bautizar al presupuesto total del proyecto, que a un no lo hemos hecho. Vamos a llamarle BAC (notar que no es m as que el coste planicado acumulado BCW S al nal del proyecto). Por otro lado, la nueva magnitud que queremos hallar va a ser el nuevo presupuesto estimado despu es de conocer la situaci on en un momento dado del proyecto, llam emosle EAC . Y ahora viene la cuenta de la vieja. Esta cuenta va a consistir en extrapolar linealmente, mediante una sencilla regla de tres, el coste real, que tenemos en un momento dado del proyecto, al nal del proyecto. Esto es, si de lo que hay que hacer (BAC ) llevo aportados BCW P , entonces de lo gastado realmente ACW P , cu anto habr e gastado cuando haya hecho lo que ten a que hacer? Este resultado es el que hemos llamado EAC , el nuevo presupuesto estimado. As pues, la regla de BAC EAC tres queda de la siguiente manera BCW = P ACW P , con lo que ya tenemos la nueva magnitud ACW P BAC . (3) BCW P As de f acil. Ya se dec a en la secci on I que era pura y simple aritm etica de andar por casa. EAC =

FIG. 2. Curvas S, costes planicado, real y valor ganado

Mediante una aritm etica extremadamente sencilla, hemos derivado dos magnitudes (f ormulas (1) y (2)) que nos dan informaci on acerca de posibles desviaciones en programaci on

SV no ofrece una medida directa de la desviaci on en plazo, no s olo porque la unidad de medida sea monetaria y no de tiempo sino porque tiene que ver m as con el esfuerzo que con la duraci on. Por ello la hemos denominado como desviaci on en programaci on (en la traducci on espa nola del PMBOK [2] se ha optado por el equivalente desviaci on del cronograma). En la secci on X se volver a a discutir esta diferencia.

Alg un lector podr a pensar que la cuenta que hemos hecho rdago que no reeja la realidad. Bueno, al no es m as que un o rdago que reexione sobre cu que le moleste lo del o antos de ellos se echan cuando se planica un proyecto. En la terminolog a ortodoxa de la Direcci on de Proyectos mejor llamarle asunci on [2], que no intimida tanto. La realidad no se puede describir de forma innitamente precisa (lo que no quiere decir que no sea objetiva); en ese caso un robot dirigir a el proyecto y santaspascuas. En estos casos una aproximaci on es mejor que nada, y una aproximaci on sencilla mejor que una compleja, por razones operativas o de no matar moscas a ca nonazos. En n, compro la cuenta de la vieja. Hechas estas consideraciones, volvamos con el segundo grupo de magnitudes derivadas. Al nuevo presupuesto estimado EAC , vamos a a nadirle un par m as. La primera es la desviaci on que tendr amos al nal el proyecto, llam emosle V AC . Esta ser a la diferencia entre el presupuesto inicial del proyecto BAC y la nueva estimaci on del mismo EAC V AC = BAC EAC . (4)

V. INTERMEZZO

Antes de continuar con m as an alisis, y denir nuevas magnitudes para medir el rendimiento del proyecto, hagamos otra parada en el camino para recapitular sobre lo que hemos hecho hasta el momento. Hemos denido tres grupos de magnitudes, de los que solamente el primero es directo mientras que el resto son deriva ste. Estos grupos son: dos aritm eticamente de e Primer grupo: magnitudes que se hallan directamente Coste planicado BCW S , se determina durante la planicaci on del proyecto. Coste realizado ACW P , se mide en un momento dado del proyecto. Valor ganado BCW P , se mide en un momento dado del proyecto. Segundo grupo: desviaciones calculadas a partir de los valores de las magnitudes anteriores en un momento dado del proyecto Desviaci on en coste CV = BCW P ACW P Desviaci on en programaci on SV = BCW P BCW S Tercer grupo: predicciones sobre la nalizaci on del proyecto calculadas a partir de extrapolar los valores de las magnitudes anteriores en un momento dado del proyecto Nueva estimaci on del presupuesto del proyecto ACW P EAC = BCW P BAC Estimaci on de la desviaci on de coste al nal del proyecto V AC = BAC EAC Estimaci on de lo que nos quedar a por gastar ET C = EAC ACW P Viendo el AVG como un proceso, la gura siguiente ilustra el diagrama de dicho proceso:

La segunda mide lo que nos quedar a por gastar, llam emosle ET C . As pues tenemos que ET C = EAC ACW P . (5)

Veamos todo esto gr acamente en la representaci on de curvas S (ver gura 3):

FIG. 3. Curvas S y extrapolaciones FIG. 4. Proceso AVG

Las l neas punteadas no se corresponden con datos reales sino con extrapolaciones. El gr aco se corresponde al caso m as com un en que vamos retrasados en plazo (programaci on) y gastando m as de lo presupuestado; en otros casos, las posiciones de las curvas diferir an entre ellas. Notar que al nal del proyecto el valor ganado BCW P coincidir a con el coste planicado acumulado BCW S , y lo mismo ocurre para cada tarea de forma individual. Esto no acaba aqu , a un podemos denir m as cosas y seguir explotando el AVG. Lo que dan de s tres magnitudes iniciales! 4

Aunque el diagrama no es completo, a un faltan m as productos de salida que restan por ver, es suciente de momento para establecer las conclusiones siguientes: En primer lugar, aunque el diagrama no sea completo en nicos su parte derecha, s lo es a su izquierda: los tres u inputs que necesitamos para alimentar el proceso son las tres magnitudes del primer grupo. Ni una m as, ni una menos.

 El proceso es pura, y extremadamente simple, algoritmia. Y como tal, puede ser automatizada y reducida a un simple darle a un bot on. nica labor proactiva a realizar es hallar los inputs. La u La buena noticia es que s olo son tres, de los que uno de ellos, el coste planicado BCW S , se halla de una vez para siempre al principio del proyecto. As s olo quedan dos a medir durante los puntos de control del proyecto. La no tan buena noticia es que la naturaleza humana no parece estar muy bien adaptada para la realizaci on de este tipo de tareas. Pero ya es un paso importante tener muy bien acotada la zona de dicultades. Si no hay input no hay outputs. Y si hay input, pero es basura, lo que debemos tener a bien seguro es que el AVG no es una planta de reciclaje. De todo esto se desprende que el AVG, a pesar de que muchos gur us se empe nen en lo contrario ocureci endolo de barroco acad emico, es simple. En todo caso la dicultad radica en buscar el forraje con que alimentarlo a trav es de las ind omitas praderas del proyecto. La moraleja es inmediata: si no hay forraje, y de buena calidad, no hay an alisis que valga. El fracaso en los intentos frustrados de utilizar el an alisis no se debe a que sea una mala herramienta o sea dif cil de utilizar, ya hemos visto cuan f acil es y cuan potente puede ser, sino a no saberla utilizar o no tener los ingredientes b asicos para ponerla en funcionamiento. Precisamente debido a su sencillez, se puede implementar de forma simple en los paquetes de software de gesti on de proyectos, como por ejemplo el MSProject. Desafortunadamente, esto se convierte en un arma de doble lo. Cada vez es m as usual que la primera toma de contacto que tienen los nuevos jefes de proyecto con las diferentes herramientas anal ticas de gesti on de proyectos, sea precisamente a trav es de estas herramientas inform aticas. Y este tipo de implementaciones no ofrecen m as que una visi on de caja negra que oculta su raz on de ser, las asunciones en que se basa, sus limitaciones de uso, etc. El resultado es que se suelen tomar como verdades universales ignorando las aproximaciones en que se basan y, por ende, sus limitaciones. En el fondo, como su propio nombre indica, no son ms que herramientas. Y, como muy bien dijo Goethe, soplar no es tocar la auta, hay que mover los dedos.
VI. INDICES DE EFICIENCIA

vi endose de repente en terreno ignoto. Sin embargo, si la lanzamos contra un elefante, quiz as ni se entere. Y es la misma canica. Se pueden comparar desviaciones de diferentes proyectos? C omo sabemos que los 20.000 C no son una canica y los 2.000 C una bola de lanzamiento de martillo? O viceversa. O, por qu e no, que ambas desviaciones son canicas a la vez? Pueden tener 2.000 C y 20.000 C el mismo peso? Est a claro que con las magnitudes que hemos denido hasta el momento no podemos responder a ninguno de estos interrogantes, a pesar de que estoy tan cansado de ver informes en los que se arma que s se responde (dime como mides y te dir e c omo te comportas) que a estas alturas igual deber a dudar de ello. Necesitamos pues de otras que s lo hagan realmente. Y as entramos en un cuarto grupo de magnitudes. Como en todas las anteriores, vamos a llegar a ellas a trav es del sentido com un. Obviamente, la eciencia de cualquier sistema deber ser medida respecto a un patr on, ya que es un t ermino relativo y no absoluto. En el caso anterior, no es lo mismo una desviaci on de 20.000 C respecto de 40.000 on los 20.000 C C que de 800.000 C. El la primera situaci son una bola de lanzamiento de martillo, y en la segunda una canica. Si dividimos una desviaci on respecto del valor patr on (a continuaci on determinaremos cu al es ese patr on), tendremos la desviaci on relativa, que no es m as que los euros que nos hemos desviado por cada euro de referencia. En la primera situaci on corresponde a un 50%, mientras que en la segunda a un 2, 5%. Y siguen siendo 20.000 C. Pero estos porcentajes, que adem as pueden ser positivos o negativos seg un las desviaciones est en a nuestro favor o en contra, no son eciencias. Una eciencia es una magnitud que suele tomar un valor entre 0 (totalmente ineciente) y 1 (eciente), e incluso ser mayor de 1 si supera su rendimiento m aximo. C omo puede ser eso? El motor de un coche dif cilmente superar a su m aximo rendimiento te orico, pero un proyecto es un claro ejemplo de sistema que s puede superar, para bien, la referencia marcada en la planicaci on. Es decir, conseguir los resultados, incluso m as de los inicialmente previstos, antes de plazo y por debajo del coste previsto. No es una cosa que cualquier profesional suela llegar a ver alguna vez durante su carrera, pero es posible. Dado que ten amos dos magnitudes que med an las desviaciones en coste y en programaci on, podemos denir sus respectivas que midan la eciencia en coste y en programaci on. Si para hallar la desviaci on hac amos una sustracci on, para la eciencia haremos una divisi on. La magnitud clave es el valor ganado BCW P . Si la referencia es el coste realizado ACW P , tendremos una eciencia en coste a la que llamaremos CP I . Si la referencia es el coste planicado BCW S , tendremos una eciencia en programaci on que llamaremos SP I . As pues, tendremos que CP I = SP I = 5 BCW P , ACW P BCW P . BCW S (6) (7)

Imaginemos al gerente de una unidad de negocio estudiando los informes de seguimiento de dos proyectos en curso. Uno de ellos le informa de que el proyecto lleva una desviaci on en coste de 20.000 C, mientras que el otro lleva una desviaci on de 2.000 C. Cu al de los dos va peor? Aparentemente, los 20.000 C del primero pican m as. Pero resulta que no pica quien quiere sino quien puede. Si lanzamos una canica contra un abejorro en pleno vuelo modicaremos, en el mejor de los casos para el abejorro, su trayectoria

En ambos casos tendremos que la eciencia es 0 si no se ha hecho nada y 1 si se va seg un lo previsto. Pero, si hemos hecho m as de lo previsto (BCW P > BCW S ), la eciencia en programaci on ser a mayor que 1; mientras que si hemos gastado menos de lo realmente aportado (ACW P < BCW P ), la eciencia en coste ser a mayor que 1. El valor 1 ser a el umbral y, adem as, as construida la eciencia, permite comparar valores de diferentes proyectos ya que dene claramente qu e es una canica o una bola de lanzamiento de martillo para cada proyecto. Con este cuarto grupo de magnitudes cerramos el tema de los indicadores. En el siguiente sitio [3] se puede encontrar un ejemplo en Excel con todas las magnitudes y c alculos automatizados del AVG. A continuaci on se muestran unas guras extra das de dicho ejemplo. En la gura 5 se muestra precisamente una evoluci on a lo largo de un proyecto de las eciencias que hemos denido anteriormente, medidas en los sucesivos puntos de control.

En color morado se muestra la evoluci on de la eciencia en coste. Esta si que es dedigna de principio a n. Vemos c omo esta eciencia va disminuyendo durante las primeras semanas del proyecto hasta que llega a un valor m nimo a partir del cual empieza a remontar, aunque siempre est a por debajo de 1. Posiblemente en ese momento se tomaron medidas importantes para recuperar el proyecto del desastre econ omico hacia ltimos estadios del proyecto obel que se encaminaba. En los u servamos c omo la eciencia vuelve a caer ligeramente, posiblemente porque se puso toda la carne en el asador para evitar que el proyecto no se fuera mucho en plazo. Se puede observar la jugosa informaci on que puede obtener un jefe de proyecto, y sobretodo un gerente, de las tendencias generales de un proyecto que muestran estos gr acos, ayudando a situar cambios en dichas tendencias de manera que ayuda a centrar los puntos donde hacer un an alisis m as exhaustivo. No todo en un proyecto es digno de especial atenci on, y estos resultados ayudan a focalizar. La gura 6 muestra la evoluci on del nuevo presupuesto, estimado en cada punto de control, a lo largo del proyecto.

FIG. 5. Eciencias en coste y programaci on

FIG. 6. Presupuesto estimado en el tiempo

En color amarillo tenemos la evoluci on de la eciencia en programaci on. Vemos c omo comenzamos haciendo m as trabajo del previsto (eciencia mayor que 1) hasta que, alrededor de la sexta semana, empieza ya a acumularse el retraso. A partir de ah la eciencia va bajando hasta que llega un momento que vuelve a subir hasta llegar a 1 al nalizar el proyecto, independientemente de que lo haga con adelanto o retraso. Este comportamiento, que puede parecer extra no, y que a un gerente no muy ducho en el AVG podr a inducirle a pensar que el director de proyecto le est a enga nando, es completamente normal debido a la forma en que se ha denido el valor ganado BCW P , que al nal del proyecto tiene que coincidir con el presupuesto inicial del proyecto BAC (ver la gura 3). Tanto la desviaci on en programaci on (1) que hemos denido, como la correspondiente eciencia (7), ser an 0 y 1, respectivamente, al nal del proyecto porque ya se habr a realizado lo que se ten a que realizar. Este comportamiento es precisamente una de las aquezas del AVG, ya que, a medida que el proyecto se va acercando a su nal, el poder informativo de estos indicadores va perdiendo fuerza. En n, no es oro todo lo que reluce. En cualquier caso, el problema se puede solventar y lo trataremos en la secci on X. 6

En azul tenemos una l nea horizontal que reeja el pre ste se muestra, en supuesto inicial BAC proyecto. Frente a e color morado, el nuevo presupuesto estimado EAC . Vemos que su historia es paralela a la de la eciencia en coste: hay un m aximo a partir del cual se tiende a recuperar el presupuesto ltimos estadios vuelve a aumentar original, hasta que en los u ligeramente. Calcado. Esto es informaci on, y de la buena.

VII. MIDIENDO EL VALOR GANADO, PRIMERA PARTE

De los cuatro grupos de magnitudes que hemos denido hasta este momento (ver secciones V y VI), el primero es el realmente fundamental y cr tico. Hasta el momento, nos hemos repetido bastante en ello, se han hecho comentarios al respecto, aunque a un no nos hemos mojado del todo y no se ha ido al fondo del asunto. Pero el an alisis que hemos visto se quedar a en un mero juego de sal on, sin utilidad pr actica, si no nos ponemos el mono de faena y tratamos de hallar esos inputs necesarios para engrasar y poner en marcha el sistema. ste es precisamente el aspecto m No en vano e as peliagudo del

AVG, no por complejo sino, m as bien, por ser un problema de tica, tres aspectos que entran dentro actitud, tes on e incluso e mbito humano. del resbaladizo a Recordemos que el primer grupo est a compuesto por el coste planicado BCW S , el valor ganado BCW P y el coste realizado ACW P . Como dijimos en la secci on II, BCW S era una proyecci on temporal, y acumulada, del presupuesto del proyecto desglosado en sus actividades y distribuido en el tiempo. Esto se consigue a partir de la programaci on de las actividades (diagrama de Gantt) y, lo que va a ser clave para el asunto que nos ocupa, del criterio que hayamos establecido para distribuir temporalmente el coste de cada una de las actividades. La siguiente gura es bastante esclarecedora de lo que acabamos de decir:

este punto donde gran parte de las organizaciones comienzan a aquear. El hecho de determinar todas las actividades a un nivel de detalle equilibrado, junto con todas sus interdependencias y su duraci on estimada, es una labor que exige m as trabajo, participaci on y compromisos de todas las partes implicadas, y una comunicacin m as uida, de lo que el nivel de madurez de muchas organizaciones puede ofrecer, o simplemente est an dispuestas a aceptar. Esto puede ser lamentable, pero es lo que hay y son hechos que un jefe de proyecto no deber a cometer el error de subestimar. Hechas estas consideraciones, nos metemos de lleno en el asunto de distribuir el coste de una actividad. El modelo que escojamos va a ser la referencia para la posterior medici on del valor ganado BCW P , que va a consistir en ir acreditando c omo se va alcanzando el valor planicado BCW S . Es por ello que a estos modelos de distribuci on tambi en se les suele llamar t ecnicas de medida del valor ganado. La esencia de todo esto es que BCW S y BCW P est an estrechamente relacionados en cuanto que el modelo elegido para distribuir el BCW S de cada actividad individual va a ser la referencia para medir posteriormente como se va ganando ese valor seg un el modelo de distribuci on. La gura siguiente deber a claricar este hecho.

FIG. 7. Programaci on y coste planicados

As , el coste planicado BCW S en un momento dado del proyecto es la suma de las siguientes contribuciones (ver secci on II): Todas aquellas tareas cuya nalizaci on planicada se haya dado en una fecha anterior a la fecha de estado dada, contribuir an con todo su coste planicado al coste planicado acumulado del proyecto. Todas aquellas tareas cuyo inicio planicado ocurra en una fecha posterior a la fecha de estado dada, no contribuir an a un al coste planicado acumulado del proyecto. Todas aquellas tareas que deber an estar en curso en la fecha de estado dada contribuir an con su fracci on de coste planicado seg un el modelo de distribuci on que se haya aplicado. Tan solo queda, pues, determinar ese modelo de distribuci on del coste para cada actividad. Pero antes de continuar debemos tener en cuenta que, hasta este punto, ya hemos asumido que hemos sido capaces de determinar todo el trabajo que hay que hacer, estructurado y desglosado en actividades, y programar estas actividades en el tiempo. En denitiva, hemos podido construir un diagrama de Gantt de todo el proyecto. Digo esto porque, en mi experiencia, es en 7

FIG. 8. Avance en programaci on y valor ganado

Comparar esta gura con la gura 7, en la que ten amos el coste planicado. Para todas aquellas tareas que han nalizado, est an completamente rellenas de color rojo, su valor ganado coincidir a con su coste planicado. Esto es as porque una vez nalizadas podemos acreditar que se ha realizado todo el trabajo previsto, independientemente de que haya habido adelantos o retrasos, o incluso se haya hecho con m as o menos coste del inicialmente previsto. Lo que importa en este caso es que se ha completado el trabajo inicialmente previsto o, en caso de no haber nalizado a un, qu e porcentaje llevamos. Sin embargo, hay otras cuyo relleno en rojo no coincide con el relleno negro planicado. En estos casos el valor ganado BCW P diferir a del coste planicado BCW S y, cuando se calcule el acumulado, tendremos una curva S (en rojo) diferente a la planicada (en negro). Se pueden ver tareas en las que se ha acreditado menos trabajo del inicialmente previsto, y otras en el que se ha acreditado m as del previsto, aunque

en el c omputo acumulado sale menos trabajo del previsto. Esto es la esencia de la medici on del valor ganado. A continuaci on abordaremos las diferentes t ecnicas para realizar esta medici on.

VIII. MIDIENDO EL VALOR GANADO, SEGUNDA PARTE

En todo lo que hemos visto hasta ahora sobre el AVG, dos m as dos sol an ser cuatro. En lo que viene a partir de ahora, es dif cil asegurarlo. Vamos a ocuparnos de lo que indistintamente nos hemos referido como modelos de distribuci on del coste de una tarea o t ecnicas de medida del valor ganado. Y digo indistintamente porque el modelo de distribuci on que escojamos va a ser la referencia para la posterior medici on del valor ganado. Si tenemos una tarea de dos semanas de duraci on (10 d as laborables) con un coste asociado de 3.500 C, cu ando decimos que se hace efectivo dicho coste? Al inicio de la tarea?, a su nalizaci on? O acaso se reparte uniformemente a raz on de 350 C diarios? De esto estamos hablando cuando nos referimos al modelo de distribuci on. Obviamente, c omo se distribuye ese coste depender a en gran medida de la propia estructura intr nseca de la tarea, y en menor manera (o mayor, por qu e no) de c omo nos interesa que se haga esa distribuci on. Y me explico. La programaci on de cierto m odulo de software compuesto de dos subsistemas tiene un coste estimado de 1.500 C, 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 umero de l neas de c odigo que contiene cada uno de los subsistemas, podr amos prorratear las cantidades entre el n umero de l neas de c odigo e ir acreditando posteriormente el coste seg un vamos teniendo l neas de c odigo; o no acreditar nada hasta que no se ha nalizado cada uno de los m odulos; o, m as sencillo a un, no acreditar los 1.500 C hasta que no se ha nalizado el m odulo entero. Despu es de todo, qu e signica tener la mitad del m odulo si por s misma no es nada. Y si se nos apura, ni tan siquiera el m odulo por s mismo es un producto acabado y lo que realmente tendr a valor es la aplicaci on de software en su totalidad. Si reunimos a varias personas tendremos opiniones para todos los gustos, y todas ellas justicadas en mayor o menor medida con razonamientos m as o menos t ecnicos, sacados de lo que dicta la experiencia diaria, etc. Los m as ingenuos abogar an por tener en cuenta todos los detalles para alcanzar la m axima precisi on posible, porque as los resultados ser an precisos, etc. Los m as resabiados nos asegurar an 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 a apreciar que se ha abierto una caja de Pandora, y mucho me temo que soy incapaz de cerrarla. Es m as, me asusta mucho cuando alguien viene diciendo que es capaz de cerrarla. En denitiva, que tiene la soluci on. Mi conclusi on personal es que no existen razones 8

denitivas que justiquen completamente un modelo concreto en un determinado contexto (algunos compa neros del PMI o defensores a ultranza del PMBOK no estar an de acuerdo conmigo), aunque no hay nada como la experiencia sensata para matizar lo que se hace en cada momento. Para ilustrar esta opini on consideremos lo que nos dicen los manuales acerca de que cu anto m as preciso sea el modelo m as 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 on de coste de la tarea?, y si entramos dentro de ella para detallar m as? Estamos como siempre, d onde empezamos (en pasado) a dejar de ser precisos?, cuan preciso se puede llegar a ser? Es c omo esas recetas diet eticas de revista dominical en las que, tras enumerar la lista de ingredientes (un vaso de aceite -qu e tipos de vaso tienes en casa amigo-, dos cucharadas de az ucar c omo vas de pulso-, dos o tres unidades de esto o lo de mas all a. . . ), nos indica que su contenido cal orico es de 95, 6 kilocalor as. Pasmao. Oiga, que se ha dejado los c entimos en su desviaci on en coste. Y el presupuesto del proyecto es de rdenes de magnidiez millones de euros! Precisamente, los o tud es otro de los aspectos que he observado que la gente no suele controlar por esos mundos empresariales. En la pr actica 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 on exquisita, a un se puede beneciar uno del uso del AVG; lo que no hay que hacer es ser exquisito donde ya no hace falta, y adem as va a ser incluso contraproducente. Considero que estas reexiones son 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 ltima instancia, suicidas defensores de las mismas que, en u pretenden justicar 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 ogica de pasos que, una vez asumidos, ya no discutimos; pero el problema no radica ah , sino con qu e delidad reeja ese modelo la parcela de realidad que pretendemos explicar l: ah con e es donde nos la jugamos de verdad y donde hay que ser especialmente cuidadosos y cr ticos. En el caso del AVG, la secuencia l ogica es todo lo que hemos explicado hasta la secci on anterior; la zona pantanosa se nos presenta con la aproximaci on del modelo, ah est a el factor limitante. Dicho todo esto, entremos ya de lleno con los modelos m as populares. El modelo m as sencillo sea, quiz as, el de reparto uniforme, ampliamente conocido en el mundo anglosaj on como nivel de esfuerzo (LOE de su acr onimo en ingl es), y est a siendo actualmente popularizado por el PMI. Para una tarea cuyo coste tenga una relaci on directa con mano de obra, este simple modelo puede reejar bastante bien la realidad. Sin embargo, si no existe esta relaci on directa, bien porque la dedicaci on no es uniforme, o porque se le imputan otro tipo de recursos aparte de la mano de obra directa, la aproximaci on ya

no es tan buena. Precisamente, el PMI recomienda su uso en aquellas tareas que no tienen un resultado tangible y que est an caracterizadas por un trabajo realizado a una tasa uniforme a lo largo del periodo de realizaci on de la tarea. Existe ste que, por su otro modelo estrechamente relacionado con e denominaci on, puede crear confusi on. Me reero al apportioned effort, que literalmente se puede traducir por esfuerzo ltimo que han escogido repartido o prorrateado, t ermino este u los compa neros que han traducido el PMBOK al espa nol. El t ermino prorrateado nos puede inducir a pensar que es el mismo que el anterior, aunque realmente se reere a tareas cuyo trabajo est a ligado a otras, como auditor as y controles de calidad, revisi on de material de aprovisionamiento, etc., y en las que su grado de avance est a ligado al grado de avance de la tarea a la que da soporte. Estos modelos, consistentes en distribuir de forma m as o menos continua el coste de una tarea a lo largo de su duraci on, se pueden complicar (y de hecho as lo hacen algunos paquetes recientes de software) para intentar reejar con mayor precisi on la realidad: por qu e ese reparto tiene que ser uniforme y no en forma de campana de Gauss para reejar que el mayor esfuerzo se concentra en la zona central? Por qu e no varios picos porque el trabajo se hace as ? Ahora bien, las matem aticas embutidas sin ton ni son en un paquete de software por gente que nunca ha sufrido un proyecto, y tan s olo se ha limitado a leerse una manual sobre m etodos 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 un el hecho de distribuir uniformemente el coste. El resto de m etodos que vamos a abordar lo hacen de forma discreta. Es el caso del ejemplo anterior del m odulo de software, en el que acredit abamos el coste al nal de la tarea. Pero tambi en se puede acreditar un porcentaje al inicio de la tarea y el restante al nal. Ejemplos son 0/100 (acreditar todo el coste al nalizar la tarea), 50/50 (mitad y mitad), 25/75 (el 25% al inicio y el 75% a la nalizaci on), y cualquier otra combinaci on. El PMI llama a este modelo f ormula ja. El modelo se puede generalizar con la inclusi on de varios hitos a lo largo de la tarea en los que acreditar coste. Por ejemplo dos hitos m as, aparte del inicio y n de la tarea, y acreditar un 15%, 35%, 35% y 15% del coste respectivamente. El PMI lo llama hitos promediados. Estos modelos son m as apropiados para tareas que tiene un resultado tangible (o resultados intermedios tangibles) a los que se ltimo modelo de puede asociar la acreditaci on de coste. El u 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 planicado de la tarea en cuesti on. Este puede que sea el m as sencillo de todos, incluso m as que el LOE, aunque arrastrar a la subjetividad acerca de con qu e se ha medido el grado de avance de la tarea. Al nal, de lo que se trata es de escoger aqu el que se considere razonablemente m as adecuado para cada contexto, y que seamos tambi en capaces de utilizar. Ante la duda o la falta de medios para la recolecci on de datos, lo mejor es uti9

lizar modelos simples como el LOE o porcentaje completado. Cuanto mayor sea el presupuesto del proyecto, en mayor medida se diluir a su inexatitud. Despu es de todo, las posibles inexatitudes se dar an en aquellas tareas que est an en curso, porque en aquellas que ya hayan nalizado ya se habr a acreditado todo el valor ganado. Y tampoco habr a muchas tareas en curso en un momento dado. Qu e puedo tener, un error de mil euros en una desviaci on de 60.000 C cuando ya se llevan ejecutados tres millones y medio de euros sobre un presupuesto total de seis millones? Apretemos m as, un error de 10.000 C? Realmente merece la pena ser m as preciso? Y ojo, que ese error se deber a al hecho de haber considerado una distribuci on uniforme en vez de una con cuatro picos acampanados, o con haber contado unos centimillos m as 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 on al orden de magnitud correspondiente. Que un euro no nos quite el sue no, amigos. Finalmente, por lo que respecta a proyectos de peque na entidad, s que hay que cuidar un poco m as las mangas. Aunque tambi en hay que estudiar si merece la pena realmente aplicar el AVG. Aunque tambi en se puede optar por la aplicaci on de versiones simplicadas 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 etodos que a los ortodoxos podr an escandalizar, aunque para los que vivimos en las trincheras hay cosas que hace tiempo que dejaron de escandalizarnos.

IX. 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 erminos de valor ganado, puede una tarea haber ganado mayor valor que su coste presupuestado? An alogamente al ejemplo anterior, depender a de lo que entendamos por valor ganado. Seg un el criterio asumido por el 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 P C , y en general de un proyecto, debe ser una magnitud cuyo recorrido vaya desde 0% (tarea cuyo inicio a un no se ha acreditado, ojo que esto no signica que no se haya iniciado) a 100% (acreditaci on de que se han alcanzado sus resultados). De la misma manera, el valor ganado BCW P de dicha tarea variar a entre cero y el coste planicado BCW S para la misma. Cuando una tarea se da por nalizada, se asume que su grado de avance es del 100% y se ha ganado todo el valor inicialmente presupuestado: BCW P = BCW S . Para el modelo sencillo de grado de avance, el c alculo del valor ganado es BCW P = P C BCW S . (8)

Otra cosa muy distinta es que en un momento dado el grado de avance que, seg un la planicaci on deber a ser del 20%, sea del 25%. O que el valor ganado acumulado hasta ese momento sea de 2.500 C, cuando el coste planicado acumulado para el mismo momento es de 2.000 C. Todo ello indica que vamos adelantados en programaci on. Pero, independientemente de que nalicemos la tarea (o proyecto) con antelaci on o retraso, nos hayamos gastado m as o menos de lo presupuestado, siempre ocurrir a que en ese momento el grado de avance es del 100% y el valor ganado ser a igual al coste planicado. No hay ninguna raz on extra na y oculta para ello, simplemente se debe a nuestra denici on de los conceptos de grado de avance y valor ganado. ptica de cierta a rea Pero resulta que el cableado de bra o estaba estimado en 10 d as, a raz on de 500 C diarios (el coste planicado ser a de BCW S = 5.000 C), y en cierto momento se nos dice que se han imputado ya 12 d as. Qu e est a ocurriendo? Llevamos un grado de avance del 120 %? Un valor ganado de 6.000 C? Obviamente se han invertido dos d as m as de los inicialmente previstos, pero eso no quiere decir que le hemos cogido gusto a eso de cablear y nos hemos rea inicialmente prevista (este caso supondr salido del a a un cambio en el alcance y, por ende, en la l nea base y el BCW S y el BAC ). Lo que ha ocurrido en realidad es que vamos con retraso. Vamos a considerar las dos posibles situaciones: 1. que hemos nalizado en 12 d as, 2. que a un no hemos nalizado. En el primer caso he nalizado en 12 d as, por lo que el grado de avance ser a del 100% y el valor ganado BCW P = BCW S = 5.000 C. Ahora bien, el coste realizado ser a de ACW P = 6.000 C. Las desviaciones ser an de CV = 1.000 C y SV = 0 C respectivamente. En el segundo caso a un no se ha nalizado, aunque ya llevamos invertidos dos d as m as de los inicialmente presupuestados. C omo calculo el grado de avance? La referencia inicial ya no nos vale porque la hemos sobrepasado. Eso nos dar a un grado de avance irreal del 120%, cuando a un no hemos nalizado! Realmente necesito una nueva estimaci on de lo que resta para nalizar. Bien, llevamos 12 d as, cu antos estimamos que nos quedan para nalizar? Supongamos que son 3 d as, eso quiere decir que la nueva duraci on estimada es 12 de 15 d as. El grado de avance ser a entonces de 15 = 80%, esto s que tiene sentido. Y ahora viene el c alculo clave que nos har a comprender en toda su amplitud el concepto de valor ganado. El valor ganado ser a el 80% del coste inicialmente presupuestado de la tarea, que era de 5.000 C, siendo BCW P = 4.000 C. As tenemos que BCW S = 5.000 C (en teor a ya deber a haber nalizado!) y ACW P = 6.000 C. Las desviaciones son CV = 2.000 C (y no mil!) y SV = 1.000 C (vamos con retraso). Para nalizar, una gura que ilustra de forma simple la relaci on entre los conceptos de coste planicado, valor ganado 10

y modelos de distribuir el coste planicado en el tiempo y medir el valor ganado.

FIG. 9. Fecha de estado y avance

La gura 9 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 planicaci on, mientras que el rojo representa lo que se ha hecho hasta la fecha representada por la l nea azul. El modelo de distribuci on es el siguiente: cada cuadradito de la rejilla que ocupan las barras de tarea representa un euro. As pues, el coste planicado acumulado hasta la fecha marcada por la l nea azul vendr a dado por la suma de todos los cuadraditos, tanto negros como rojos (notar que en planicaci on son todos negros) que est en situados a la izquierda de la l nea azul. Son 33 cuadraditos: BCW S = 33 C. Eso es todo lo que se deber a haber hecho seg un lo planicado. El valor ganado es todo lo que se ha hecho hasta la fecha y vendr a dado por la suma de todos los cuadraditos de color rojo, tanto si est an 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: BCW P = 29 C. La desviaci on en programaci on es (ver f ormula (1)) SV = BCW P BCW S = 4 C. El proyecto en su totalidad va con retraso.
GANADA X. EL CONCEPTO DE PROGRAMACION

En la secci on VI, donde se trataban los diferentes indicadores para medir la eciencia de un proyecto, descubrimos que el ndice de eciencia en programaci on SP I y la desviaci on en programaci on SV presentaban un compor ltimos estadios del tamiento aparentemente an omalo en los u proyecto. En efecto, si rescatamos el historial de desviaciones del ejemplo [3] (ver gura 10), observamos que, mientras la desviaci on en coste CV (curva en amarillo) sigue una tendencia decreciente a lo largo del proyecto, la desviaci on en programaci on SV (curva en morado) invierte esa tendencia a partir de la semana 20, m as o menos. Parece como si el proyecto se hubiera recuperado en plazo y nalmente hubiera terminado en el plazo previsto, cuando en realidad ha nalizado dos meses m as tarde (ver el ejemplo [3]). Algo similar ocurre con las respectivas eciencias (ver la gura 5). En realidad, este hecho no es m as que una consecuencia de la denici on del concepto de valor ganado BCW P , magnitud que, por construcci on, tiene que coincidir

con el coste planicado BCW S del proyecto en el mismo momento de su nalizaci on, esto es el BAC . Aunque ello no quita para que perdamos el poder informativo de estas magnitudes relacionadas con la programaci on y el plazo. Como anunciamos en su momento, esto constitu a una aqueza del AVG. Afortunadamente no es un escollo que no se pueda solventar.

La programaci on ganada, que denotaremos por ES , no es m as que la fecha en la que el coste planicado acumulado BCW S del proyecto es igual al valor ganado acumulado BCW P en la fecha de estado AT . Si el proyecto sigue a rajatabla su curso planicado, estas fechas coincidir an. En caso contrario, no; como se muestra en la gura 11 para el caso en que hay retraso. Es importante resaltar que la introducci on de esta nueva magnitud no supone incrementar el n umero de magnitudes que se miden directamente, ya que se mide a partir de otras. Es una magnitud derivada (ver la secci on V). 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 on y eciencia en programaci on que sustituyan a las del AVG. En primer lugar, denimos la desviaci on en programaci on SV (t) como SV (t) = ES AT , mientras que la correspondiente eciencia como (9)

FIG. 10. Desviaciones de coste y programaci on

SP I (t) =

ES . AT

(10)

Hay que resaltar que esta aqueza no quiere decir para nada que el valor ganado sea un mal concepto. Todo lo contra ltimos conceptos m rio. Es uno de los u as importantes que se han aportado a la disciplina de la Direcci on de Proyectos. S olo el hecho de permitir obtener desviaciones en coste realistas frente a las malas pr acticas, aunque muy extendidas, de medirlas respecto al presupuesto inicial, ya es un gran avance nico es que hemos encontrado que tiene sus en s mismo. Lo u limitaciones a la hora de tratar la programaci on. Unas limitaciones que se pueden superar extendiendo el m etodo. Y aqu es donde entra el concepto de Programaci on Ganada. En realidad, es una idea an aloga a la del Valor Ganado, aunque en vez de utilizar unidades monetarias para medir desviaciones y eciencias de programaci on se utilizan unidades de tiempo. El concepto de programaci on ganada, como todos los que hemos visto del AVG, es extremadamente simple e intuitivo.

Y ya est a todo. Ahora tan solo resta determinar c omo se calcula la programaci on ganada EV . Pero antes hagamos una peque na reexi on acerca de la interpretaci on de la desviaci on en programaci on SV (t), medida en unidades de tiempo (d as, semanas, meses, etc.). Tiene algo que ver esta desviaci on con la que me dar a un diagrama de Gantt? Si echamos un vistazo a la gura 11, vemos que la desviaci on se calcula a partir de la diferencia entre valores acumulados del coste planicado y el valor ganado. Valores acumulados. En cambio, en un diagrama de Gantt, una desviaci on en plazo de, digamos, una semana se puede deber tanto a que una tarea posee una desviaci on de una semana como que cinco tareas en paralelo posean todas ellas una desviaci on de una semana. Aunque la desviaci on es de una semana en ambos casos, a nadie se le escapa que el segundo caso es m as dif cil de recuperar que el primero, debido ha que hay m as trabajo sin hacer. Esto no es m as que una manifestaci on de la diferencia que hay entre esfuerzo y duraci on. La desviaci on en programaci on dada por la programaci on ganada tiene que ver con el esfuerzo. 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. Imaginemos que nos comunican que llevamos 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 on en plazo que la obtengo a partir de un diagrama de Gantt, y una desviaci on en programaci on que obtenemos a partir del AVG extendido. Ahora volvamos al asunto de c omo calcular la programaci on ganada ES . Considerando el ejemplo de la gura 11, la programaci on ganada deber a tener un valor comprendido entre los meses 5 y 6. Denotemos por x dicha fracci on de tiempo, como se muestra en la gura 12: 11

FIG. 11. Concepto de programaci on ganada

Dado que el tri angulo peque no y el grande est an a escala entre ellos, por relaciones de semejanza obtenemos el valor P (7)BCW S (5) de la fracci on x. A saber x = BCW BCW S (6)BCW S (5) . En general, para una programaci on ganada ES que se encuentre entre el instante de tiempo n y el n + 1, tendremos que BCW P (AT )BCW S (n) x = BCW on S (n+1)BCW S (n) , con lo que la programaci ganada ser a ES = n + BCW P (AT ) BCW S (n) . BCW S (n + 1) BCW S (n) (11)

Y ahora vamos a ver c omo se utiliza esta traca, que as parece m as de lo que es. En el ejemplo de la tabla de la gura 14 4127 tenemos que ES = 6 + 4257 un la 51224127 = 6, 1 meses, seg f ormula (11). As de simple.
FIG. 12. C alculo de la programaci on ganada (1)

rea deliLas claves para el c alculo las encontramos en el a mitada por el c rculo verde. Y ahora es cuando viene la aproximaci on, a estas alturas ya deber amos estar acostumbrados a ello. Vamos a considerar que la porci on de curva BCW S comprendida entre los valores BCW S (5) y BCW S (6) es recta. Hay dos consideraciones que podemos extraer de esto: 1. Esta asunci on se aproximar a m as a la realidad cuanto m as peque na sea la escala de la dimensi on temporal (eje horizontal). Esto es, semanas mejor que meses, meses 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 a cualquier efecto producido por ser m as preciso. 2. Hay que desconar de aquellos que emiten juicios categ oricos del tipo la l ogica matem atica demuestra que. . . . La matem atica dir a lo que tenga que decir en su contexto. En el que nos manejamos nosotros ser a m as conveniente un juicio del tipo los siguientes resultados ofrecen una desviaci on bastante aproximada por la raz on que. . . . La experiencia suele decir que cuanto m as categ orico es un argumento, menor es la idea que tiene sobre el asunto el que argumenta (la ignorancia se suple con supuesta autoridad). Pero continuemos con el c alculo. Si ampliamos la zona rodeada por el c rculo verde, tenemos la gura siguiente:

FIG. 14. Ejemplo

Para completar la exposici on retomaremos el ejemplo de la secci on VI. En el siguiente sitio [4] se puede encontrar otro ejemplo en Excel con la actualizaci on del anterior [3] a la extensi on de la programaci on ganada. A continuaci on se mues ltimo ejemplo, que tran un par de guras extra das de este u nos sirve para comentar las comparaciones entre las antiguas desviaci on y eciencia en programaci on, y las nuevas. En la gura 15 se muestra el historial de las desviaciones. Esta gura es la misma que la gura 10, salvo que ahora se incluye la nueva desviaci on en programaci on SV (t) en color azul, medida en meses seg un la escala vertical de la derecha.

FIG. 13. C alculo de la programaci on ganada (2)

FIG. 15. Desviaciones en coste y programaci on

12

Podemos comprobar que este indicador s que proporciona buena informaci on hasta el nal del proyecto, a diferencia del anterior (en color amarillo). Al nal del proyecto, la desviaci on es de dos meses, justo el retraso que ha tenido el proyecto. Tambi en se puede ver c omo hacia el nal del proyecto se hace un esfuerzo para recuperar plazo y que no termine con m as retraso a un. Como ya dijimos en su momento, esto nos da informaci on de la buena. La gura 16 muestra el historial de eciencias:

BCW P : Budgeted Cost of Work Performed (Coste presupuestado del trabajo realizado). ACW P : Actual Cost of Work Performed (Coste real del trabajo realizado). SV : Schedule Variance (Desviaci on en programaci on). CV : Cost Variance (Desviaci on en coste). SP I : Schedule Performace Index ( Indice de eciencia en programaci on). CP I : Cost Performace Index ( Indice de eciencia en coste). EAC : Estimated At Completion (Presupuesto estimado a la nalizaci on). ET C : Estimated To Completion (Presupuesto remanente hasta la nalizaci on). AT : Actual Time (Tiempo real o fecha de estado). ES : Earned Schedule (Programaci on ganada). SV (t): Schedule Variance (Desviaci on en programaci on, ver f ormula (9)). SP I (t): Schedule Performace Index ( Indice de eciencia en programaci on, ver f ormula (10)).

AGRADECIMIENTOS FIG. 16. Eciencias en coste y programaci on

Nuevamente observar las diferencias entre la curva amarilla (la antigua), y la azul (la nueva). La azul es able hasta el nal. El concepto de Programaci on Ganada se debe a Walt Lipke, quien lo present o en una publicaci on [5] en marzo de 2003 cuando estaba al cargo de la divisi on de software del Centro de Log stica A erea de Oklahoma. Walt Lipke ha desarrollado asimismo una hoja Excel en el que ha automatizado los c alculos de las diferentes magnitudes asociadas a la Programaci on Ganada. Se puede descargar desde este sitio [6] en su versi on original en ingl es, o desde aqu [7] en espa nol.

Quiero agradecer a Walt Lipke el permiso para traducir al espa nol la hoja de c alculo de la Programaci on Ganada y distribuirla entre la comunidad de habla espa nola.

REFERENCIAS [1] http://direccion-proyectos.blogspot.com/2006/03/tampocohay-que-cebarse-con-la.html [2] Project Management Institute (PMI). Gu a de los Fundamentos de la Direcci on de Proyectos (PMBOK) (3 ed.). PMI 2004. [3] http://direccion-proyectos.blogspot.com/2006/07/seguimientode-proyectos-con-el 13.html [4] http://direccion-proyectos.blogspot.com/2006/09/seguimientode-proyectos-con-el 08.html [5] http://www.earnedschedule.com/Docs/Schedule is Different.pdf [6] http://www.earnedschedule.com/Calculator.shtml [7] http://www.armell.com/excel/ES Calculator V2a Copyright 2004 Lipke Spanish.zip [8] H. Kerzner, Project Management: A Systems Approach to Planning, Scheduling, and Controlling (9 ed.). New York: Wiley & Sons 2006. [9] Meredith and Mantel, Project Management: a Managerial Approach (6 ed.). New York: Wiley & Sons 2006. [10] Q. W. Fleming and J. M. Koppelman, Earned Value Project Management (2 ed.). PMI 2000. [11] PMI, Practice Standard for Earned Value Management. PMI 2005. [12] J. Davidson Frame, La nueva direccin de proyectos. Ediciones Granica 2000.

XI. GLOSARIO

La notaci on utilizada para representar las diferentes magnitudes utilizadas a lo largo de este art culo es la est andar y tradicionalmente utilizada en la literatura anglosajona [8] [9] [10] [11]. En [12], t tulo traducido al espa nol, se utiliza una notaci on tambi en traducida y muy pr oxima a la del paquete de software MSProject. A continuaci on se muestra una lista de los t erminos utilizados con su denici on en ingl es y su traducci on al espa nol. BCW S : Budgeted Cost of Work Scheduled (Coste presupuestado del trabajo programado).

Algunos derechos reservados. Este art culo se licencia bajo Creative Commons (http://creativecommons.org/licenses/by-nc-sa/2.5/es/).

13