Anexo II. Seguimiento de Proyectos Con El AnÃ¡Lisis Del Valor Ganado

Seguimiento de proyectos con el Análisis del Valor Ganado Anexo II
Anexo II. Seguimiento de proyectos con el Análisis del Valor

Ganado
El método del Análisis del Valor Ganado (AVG) es una técnica extremadamente
sencilla, a pesar de la sensación diametralmente opuesta que puede provocar la
reciente explosión en la literatura de títulos aparentemente sofisticados dedicados al
tema, así como el poco uso práctico que se le da en nuestro país. Para rellenar este
vaco, el propósito de este artículo es intentar demostrar cuan sencilla es su aplicación
y ofrecer unas claves para un uso correcto y, sobretodo, adecuado.
A2.1. El por qué
Vamos a comenzar interrogándonos por su motivación. Consideremos que en

cierto momento de la ejecución de un proyecto reunimos información sobre todos los
gastos producidos hasta ese momento. Entre estos gastos se encuentran los costes de
la mano de obra asignada al proyecto, según sus horas imputadas al proyecto; pedidos
efectuados a proveedores y otros conceptos derivados de la subcontratación; gastos
derivados del uso de infraestructuras como alquileres, recibos de luz, etc.; gastos por
dietas y desplazamientos; gastos financieros; y otros mas no citados en esta lista. En
definitiva, cualquier salida de la tesorera de la organización imputable al proyecto en
cuestión. Pues bien, supongamos que esta cantidad asciende a 800.000 €. Ahora
consideremos que tenemos un plan de proyecto más o menos en condiciones, con una
predicción de la programación del trabajo a realizar (esto es, las tareas a realizar con su
duración estimada y calendario de ejecución) y un presupuesto elaborado a partir de la
proyección de costes a lo largo del proyecto. Con todo esto supongamos que, a la
fecha en que hemos recabado la información sobre gastos, el coste presupuestado
acumulado hasta esa fecha es de 750.000 €.
Todo indica que llevamos gastados 50.000 € de más. Pero, ¿es correcta esta
afirmación? En este pequeño y rápido análisis monetario nos hemos dejado otro
aspecto fundamental del proyecto: su plazo. Para ser más precisos, cabrá preguntarse:
¿hemos realizado todo el trabajo programado hasta la fecha? Porque si no es así, si es
menos trabajo, la desviación en coste deberá 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ás trabajo del inicialmente presupuestado,
igual resulta que los cincuenta mil extra indican, más que una desviación en coste, que
hemos adelantado trabajo. Esto es, podría no haber tal desviación 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ón temporal. El AVG hace
precisamente eso, y nada más.
149 Valme Fernández Hueso Ingeniero Industrial

Proyecto fin de carrera: Análisis de Riesgos en la Gestión de Proyectos. Aplicación a
un CRM.
Así pues, además de los conceptos anteriores de coste real (antes nos hemos
referido como gasto) y coste presupuestado, debemos añadir el coste presupuestado
del trabajo realizado (comúnmente 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ás que consecuencias inmediatas de manipular de una forma
extremadamente sencilla estos tres conceptos.
A2.2. Curvas S
Una vez vistas las motivaciones, y antes de pasar al cómo, efectuaremos una
pequeña parada en el camino para ver que alforjas debemos preparar antes de
embarcarnos en el viaje a través del sendero del AVG.
El primer ingrediente que necesitamos, y el más fundamental de todos, es

disponer de un presupuesto desglosado a través de todas las actividades en que
hemos estructurado el proyecto, y distribuido en el tiempo. Esta proyección temporal
se obtiene en base a dos acciones básicas:
1. se ha efectuado una programación 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.
Existen múltiples maneras de hacer esto último según la situación concreta

ante la que nos encontremos: trabajo efectuado por mano de obra directa o
subcontratada; actividades de aprovisionamiento; distribución lineal a lo largo de la
duración de la tarea o discreta en momentos puntuales; otras distribuciones más o
menos variopintas, curiosas, y hasta exóticas, que nos ofrecen los paquetes de
software; etc. En estos casos lo mejor es aplicar un sentido común entrenado y, ante
todo, pecar mas de simplicidad en el modelo aplicado que de lo contrario [1].
Esta última advertencia pudiera parecer gratuita, pero no lo es. Parece mentira
observar cómo se puede pasar de no llevar absolutamente ningún tipo de gestión
cuantitativa en un proyecto a intentar llevarla y, entonces, demandar que esta sea de
una precisión exquisita. Bueno, los típicos movimientos pendulares del ser humano.
Esto se suele dar entre gente poco entrenada o, aunque lo este, con poca capacidad de
abstracción, inducción y falta de espíritu crítico. Hay que tener presente que a partir de
cierto nivel de precisión la realidad no va a coincidir con nuestra planificación, por
mucho que nos esforcemos en lo contrario [1]. En definitiva, lo que conseguimos con
esto es disponer, para una fecha dada de nuestro proyecto, de un coste planificado
acumulado del proyecto, que es la suma de las siguientes contribuciones:

un CRM.
• Todas aquellas tareas cuya finalización planificada se haya dado en una fecha
anterior a la fecha de estado dada, contribuirán con todo su coste planificado al
coste planificado acumulado del proyecto.
• Todas aquellas tareas cuyo inicio planificado ocurra en una fecha posterior a
la fecha de estado dada, no contribuirán aun al coste planificado acumulado del
proyecto.
• Todas aquellas tareas que deberían estar en curso en la fecha de estado dada
contribuirán con su fracción de coste planificado según el modelo de
distribución que se haya aplicado.
Figura A2.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ón hacia el final cuando ya estamos próximos a
agotar todo el presupuesto. Esta curva es muy propia de fenómenos auto limitados
como el consumo de un presupuesto, el crecimiento de la población de cierta especie
de un ecosistema, o el número de nuevos edificios construidos en el litoral
mediterráneo -por citar un ejemplo de rabiosa actualidad en el momento en que este
artículo ve la luz.

un CRM.
A2.3. El cómo
Si en la sección anterior se hacía especial hincapié en el presupuesto

desglosado y proyectado en el tiempo, como un requisito necesario para poder
abordar el análisis, era porque precisamente va a constituir el marco de referencia
respecto del cual se va a medir el rendimiento del proyecto. Y no pensemos solamente
en términos monetarios, sino también en términos de plazo. De ahí la insistencia en
que el desglose no deba limitarse a las tareas en que se haba estructurado el proyecto,
sino también 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 fijado en el momento de realizar la
planificación detallada.
Una vez la ejecución del proyecto se vaya abriendo paso, se procederá 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 final del proyecto, el análisis es totalmente automático. Dicho de esta manera,
la cosa parece bastante simple. Pero no lo es para nada. El ser humano es capaz de
desentrañar las aparentemente complejas leyes que rigen la naturaleza, diseñar y
ejecutar complicados procesos de ingeniera, idear y aprender técnicas 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 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 formulas complicadas, sino todo lo contrario. A la hora de obtener datos sobre
costes reales y valores ganados ocurre lo mismo. Quizás el coste real (ver la sección I)
sea algo más 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ás difícil.
El valor ganado es una magnitud crucial para nuestro análisis, no en balde de

ahí recibe su nombre el AVG. En sensu stricto no es más que el coste presupuestado
del trabajo realizado, una foto instantánea del progreso del trabajo en un momento
dado del proyecto, valorado según el coste presupuestado. Si el progreso del trabajo
de una actividad coincide con el inicialmente previsto, el valor ganado coincidirá con su
coste planificado. La suma de todas las contribuciones de todas las tareas finalizadas o
en curso en el momento de tomar la instantánea, nos dará el valor acumulado para
cada una de las magnitudes mencionadas. Si ambos valores coinciden, podemos

un CRM.
concluir que el proyecto marcha según el plazo previsto; en caso contrario indicara que
marcha adelantado o atrasado. Podemos definir una magnitud para medir esta
desviación de la siguiente manera
SV = BCWP − BCWS, (1)
Donde BCWP es el valor ganado, BCWS el coste planificado y SV, al que

llamaremos desviación en programación, nos da una medida de la desviación en plazo,
aunque en Unidades monetarias. Si SV es una cantidad negativa, quiere decir que el
valor ganado ha sido menor que el coste planificado 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ón, por lo que tendríamos que haber gastado más 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ún el coste presupuestado. Eso no quiere decir que
nos hayamos gastado realmente ese dinero. Este último valor lo da el coste realizado
que, como su nombre indica, no es más 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ón en coste del proyecto
CV = BCWP − ACWP, (2)
Donde ACWP es el coste realizado y CV la desviación en coste. Si la desviación

en coste es negativa quiere decir que estamos gastando más 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 solo remitirnos a lo que
se decía en la sección II: sentido común entrenado y, ante todo, pecar mas de
simplicidad en el modelo aplicado que de lo contrario (ver sección VIII para más
detalle). Una vez determinado el progreso, el valor ganado se obtiene multiplicándolo
por el coste planificado de la tarea (ver sección VIII). En la representación grafica
mediante curvas S tenemos lo siguiente:

un CRM.
Figura A2.2. Curva S, costes planificado, real y valor ganado
Mediante una aritmética extremadamente sencilla, hemos derivado dos

magnitudes (fórmulas 1 y 2) que nos dan información acerca de posibles desviaciones
en programación, predicción y coste. La cosa no acaba aquí además podemos derivar
nuevas magnitudes que permiten efectuar una predicción acerca de cuál podría ser el
coste final del proyecto si las cosas continuaran según la tendencia actual.
A2.4. Predicciones
Las dos magnitudes (1), (2) derivadas en la sección anterior nos dan la
desviación en coste y la desviación en programación 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ómo quede afectado por las desviaciones en que se
ha incurrido hasta el momento, se realizara según el esfuerzo inicialmente previsto, el
proyecto finalizaría con las desviaciones citadas pero aún siendo un pronóstico
pesimista (en el caso de desviaciones negativas), quizás sea mucho más optimista de lo
que creemos.
¿Qué ocurriría si esta tendencia de desviarse del plan previsto continúa a lo

largo de todo el proyecto?: sobre todo si no se hace nada por remediarlo. Aquí es
donde entramos en el segundo grupo de magnitudes derivadas del AVG (el primero

un CRM.
estaba constituido por las desviaciones en coste y programación). Como se adelantaba

en la sección anterior, una de estas nuevas magnitudes permite efectuar una
predicción acerca cuál podría ser el coste al final del proyecto, si las cosas continuaran
según la tendencia actual.
¿Cómo construir esta nueva magnitud? Pues mediante la cuenta de la vieja.

Pero, antes de contar, vamos a bautizar al presupuesto total del proyecto, vamos a
bautizar al presupuesto total del proyecto, que aún no lo hemos hecho.
Vamos a llamarle BAC (notar que no es más que el coste planificado acumulado
BCWS al final del proyecto). Por otro lado, la nueva magnitud que queremos hallar va a
ser el nuevo presupuesto estimado después de conocer la situación en un momento
dado del proyecto, llamémosle EAC. Y ahora viene la cuenta de la vieja. Esta cuenta va
a consistir extrapolar linealmente, mediante una sencilla regla de tres, el coste real,
que tenemos en un momento dado del proyecto, al final del proyecto. Esto es, si de lo
que hay que hacer (BAC) llevo aportados BCWP, entonces de lo gastado realmente
ACWP, ¿cuánto habrá 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 tres queda de la siguiente manera BAC/BCWP=EAC/ACWP, con lo que la
tenemos la nueva magnitud
(3)
Así de fácil. Ya se decía en la sección I que era pura y simple aritmética de andar
por casa. Algún lector podrá pensar que la cuenta que hemos hecho no es más que un
órdago que no refleja la realidad. Bueno, al que le moleste lo del órdago que reflexione
sobre cuántos de ellos se echan cuando se planifica un proyecto. En la terminología
ortodoxa de la Dirección de Proyectos mejor llamarle asunción (2), que no intimida
tanto. La realidad no se puede describir de forma infinitamente precisa (lo que no
quiere decir que no sea objetiva); en ese caso un robot dirigiría el proyecto y santas
pascuas. En estos casos una aproximación es mejor que nada, y una aproximación
sencilla mejor que una compleja, por razones operativas o de no matar moscas a
cañonazos. En fin, 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ñadirle un par más. La
primera es la desviación que tendríamos al final del proyecto, llamémosle VAC. Esta
será la diferencia entre el presupuesto inicial del proyecto BAC y la nueva estimación
del mismo EAC
VAC = BAC – EAC (4)

un CRM.
La segunda mide lo que nos quedaría por gastar, llamémosle ETC. Así pues
tenemos que:
ETC = EAC – ACWP (5)
Veamos todo esto en la representación de las curvas S (ver Figura 3):
Figura A2.3. Curva S y extrapolaciones
Las líneas punteadas no se corresponden con datos reales sino con

extrapolaciones. El grafico se corresponde al caso más común en que vamos
retrasados en plazo (programación) y gastando más de lo presupuestado; en otros
casos, las posiciones de las curvas diferirán entre ellas. Notar que al final del proyecto
el valor ganado BCWP coincidirá con el coste planificado acumulado BCWS, y lo mismo
ocurre para cada tarea de forma individual. Esto no acaba aquí, aun podemos definir
más cosas y seguir explotando el AVG. ¡Lo que dan de sí tres magnitudes iniciales!

un CRM.
A2.5. Intermezzo
Antes de continuar con más análisis, y definir 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 definido tres grupos de magnitudes, de los que solamente el primero es

directo mientras que el resto son derivados aritméticamente de este. Estos grupos
son:
• Primer grupo: magnitudes que se hallan directamente

– Coste planificado BCWS, se determina durante la planificación del proyecto.
– Coste realizado ACWP, se mide en un momento dado del proyecto.
– Valor ganado BCWP, 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ón en coste CV = BCWP − ACWP
– Desviación en programación SV = BCWP – BCWS
• Tercer grupo: predicciones sobre la finalización del proyecto calculadas a partir de

extrapolar los valores de las magnitudes anteriores en un momento dado del proyecto
– Nueva estimación del presupuesto del proyecto
EAC = ACWP
BCWP × BAC
– Estimación de la desviación de coste al final del proyecto
V AC = BAC − EAC
– Estimación de lo que nos quedara por gastar
ETC = EAC − ACWP
Viendo el AVG como un proceso, la figura siguiente ilustra el diagrama de dicho

proceso:
Figura A2.4 Proceso AVG

un CRM.
Aunque el diagrama no es completo, aun faltan más productos de salida que

restan por ver, es suficiente de momento para establecer las conclusiones siguientes:
 En primer lugar, aunque el diagrama no sea completo en su parte derecha, sí lo

es a su izquierda: los tres únicos inputs que necesitamos para alimentar el
proceso son las tres magnitudes del primer grupo. Ni una más, 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ón”.
• La única labor proactiva a realizar es hallar los inputs. La buena noticia es que
solo son tres, de los que uno de ellos, el coste planificado BCWS, se halla de
una vez para siempre al principio del proyecto. As solo 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ón de
este tipo de tareas. Pero ya es un paso importante tener muy bien acotada la
zona de dificultades.
• 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ús se empeñen
en lo contrario oscureciéndolo de barroco académico, es simple. En todo caso la
dificultad radica en buscar el forraje con que alimentarlo a través de las indómitas
praderas del proyecto. La moraleja es inmediata: si no hay forraje, y de buena calidad,
no hay análisis que valga. El fracaso en los intentos frustrados de utilizar el análisis no
se debe a que sea una mala herramienta o sea difícil de utilizar, ya hemos visto cuán
fácil es y cuan potente puede ser, sino a no saberla utilizar o no tener los ingredientes
básicos para ponerla en funcionamiento.
Precisamente debido a su sencillez, se puede implementar de forma simple en

los paquetes de software de gestión de proyectos, como por ejemplo el MS Project.
Desafortunadamente, esto se convierte en un arma de doble filo. Cada vez es más
usual que la primera toma de contacto que tienen los nuevos jefes de proyecto con las
diferentes herramientas analíticas de gestión de proyectos, sea precisamente a través
de estas herramientas informáticas. Y este tipo de implementaciones no ofrecen más
que una visión de caja negra que oculta su razón 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 flauta, hay que mover los dedos”.

un CRM.
A2.6. Índices de eficiencia
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ón en coste de 20.000 €, mientras que el otro lleva una desviación de
2.000 €. ¿Cuál de los dos va peor? Aparentemente, los 20.000 € del primero pican mas.
Pero resulta que no pica quien quiere sino quien puede. Si lanzamos una canica contra
un abejorro en pleno vuelo modificaremos, en el mejor de los casos para el abejorro,
su trayectoria, viéndose de repente en terreno ignoto. Sin embargo, si la lanzamos
contra un elefante, quizás ni se entere. Y es la misma canica. ¿Se pueden comparar
desviaciones de diferentes proyectos? ¿Como sabemos que los 20.000 € no son una
canica y los 2.000 € una bola de lanzamiento de martillo? O viceversa. O, por qué no,
¿que ambas desviaciones son canicas a la vez? ¿Pueden tener 2.000 € y 20.000 € el
mismo peso?
Está claro que con las magnitudes que hemos definido 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 afirma que si se responde (dime como mides y
te diré como te comportas) que a estas alturas igual deberá dudar de ello.
Necesitamos pues de otras que si lo hagan realmente. Y as entramos en un

cuarto grupo de magnitudes. Como en todas las anteriores, vamos a llegar a ellas a
través del sentido común. Obviamente, la eficiencia de cualquier sistema deber ser
medida respecto a un patrón, ya que es un término relativo y no absoluto. En el caso
anterior, no es lo mismo una desviación de 20.000 € respecto de 40.000€ que de
800.000€. En la primera situación los 20.000 € son una bola de lanzamiento de
martillo, y en la segunda una canica. Si dividimos una desviación respecto del valor
patrón (a continuación determinaremos cual es ese patrón), tendremos la desviación
relativa, que no es más que los euros que nos hemos desviado por cada euro de
referencia. En la primera situación corresponde a un 50%, mientras que en la segunda
a un 2,5%. Y siguen siendo 20.000 €.
Pero estos porcentajes, que además pueden ser positivos o negativos según las
desviaciones estén a nuestro favor o en contra, no son eficiencias. Una eficiencia es
una magnitud que suele tomar un valor entre 0 (totalmente ineficiente) y 1 (eficiente),
e incluso ser mayor de 1 si supera su rendimiento máximo. ¿Cómo puede ser eso? El
motor de un coche difícilmente superara su máximo rendimiento teórico, pero un
proyecto es un claro ejemplo de sistema que si puede superar, para bien, la referencia
marcada en la planificación. Es decir, conseguir los resultados, incluso más 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ón, podemos definir sus respectivas que midan la eficiencia en coste y en
programación. Si para hallar la desviación hachamos una sustracción, para la eficiencia

un CRM.
haremos una división. La magnitud clave es el valor ganado BCWP. Si la referencia es el

coste realizado ACWP, tendremos una eficiencia en coste a la que llamaremos CPI. Si
la referencia es el coste planificado BCWS, tendremos una eficiencia en programación
que llamaremos SPI. As pues, tendremos que
CPI = BCWP/ACWP, (6)
SPI = BCWP/BCWS, (7)
En ambos casos tendremos que la eficiencia es 0 si no se ha hecho nada y 1 si

se va según lo previsto. Pero, si hemos hecho más de lo previsto (BCWP > BCWS), la
eficiencia en programación será mayor que 1; mientras que si hemos gastado menos
de lo realmente aportado (ACWP < BCWP), la eficiencia en coste será mayor que 1. El
valor 1 será el umbral y, además, as construida la eficiencia, permite comparar valores
de diferentes proyectos ya que define claramente que 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álculos automatizados del AVG. A continuación se muestran unas figuras extraídas
de dicho ejemplo. En la figura 5 se muestra precisamente una evolución a lo largo de
un proyecto de las eficiencias que hemos definido anteriormente, medidas en los
sucesivos puntos de control.
Figura A2.5. Eficiencias en coste y programación

un CRM.
En color amarillo tenemos la evolución de la eficiencia en programación. Vemos

como comenzamos haciendo más trabajo del previsto (eficiencia mayor que 1) hasta
que, alrededor de la sexta semana, empieza ya a acumularse el retraso. A partir de ahí
la eficiencia va bajando hasta que llega un momento que vuelve a subir hasta llegar a 1
al finalizar el proyecto, independientemente de que lo haga con adelanto o retraso.
Este comportamiento, que puede parecer extraño, y que a un gerente no muy ducho
en el AVG podrá inducirle a pensar que el director de proyecto le está engañando, es
completamente normal debido a la forma en que se ha definido el valor ganado BCWP,
que al final del proyecto tiene que coincidir con el presupuesto inicial del proyecto BAC
(ver la figura 3). Tanto la desviación en programación (1) que hemos definido, como
la correspondiente eficiencia (7), serán 0 y 1, respectivamente, al final del proyecto
porque ya se habrá realizado lo que se tena que realizar. Este comportamiento es
precisamente una de las flaquezas del AVG, ya que, a medida que el proyecto se va
acercando a su final, el poder informativo de estos indicadores va perdiendo fuerza. En
fin, no es oro todo lo que reluce. En cualquier caso, el problema se puede solventar y
lo trataremos en la sección X.
En color morado se muestra la evolución de la eficiencia en coste. Esta sí que es

fidedigna de principio a fin. Vemos como esta eficiencia 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á por debajo de 1. Posiblemente en ese
momento se tomaron medidas importantes para recuperar el proyecto del desastre
económico hacia el que se encaminaba. En los últimos estadios del proyecto
observamos como la eficiencia 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ón que puede obtener un jefe de
proyecto, y sobre todo un gerente, de las tendencias generales de un proyecto que
muestran estos gráficos, ayudando a situar cambios en dichas tendencias de manera
que ayuda a centrar los puntos donde hacer un análisis más exhaustivo. No todo en un
proyecto es digno de especial atención, y estos resultados ayudan a focalizar. La figura
6 muestra la evolución del nuevo presupuesto, estimado en cada punto de control, a lo
largo del proyecto.

un CRM.
Figura A2.6. Presupuesto estimado en el tiempo
En azul tenemos una línea horizontal que refleja el presupuesto inicial BAC
proyecto. Frente a este se muestra, en color morado, el nuevo presupuesto estimado
EAC. Vemos que su historia es paralela a la de la eficiencia en coste: hay un máximo a
partir del cual se tiende a recuperar el presupuesto original, hasta que en los últimos
estadios vuelve a aumentar ligeramente. Calcado. Esto es información, y de la buena.
A2.7. Midiendo el Valor Ganado, Primera Parte
De los cuatro grupos de magnitudes que hemos definido 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ún no nos hemos mojado del todo y no se
De los cuatro grupos de magnitudes que hemos definido 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 aun no nos hemos mojado del todo y no se ha ido al fondo del
asunto. Pero el análisis que hemos visto se quedara en un mero juego de salón, sin
utilidad práctica, si no nos ponemos el mono de faena y tratamos de hallar esos inputs
necesarios para engrasar y poner en marcha el sistema. No en vano este es
precisamente el aspecto más peliagudo del AVG, no por complejo sino, más bien, por
un CRM.
ser un problema de actitud, tesón e incluso ética, tres aspectos que entran dentro del
resbaladizo ámbito humano.
Recordemos que el primer grupo está compuesto por el coste planificado

BCWS, el valor ganado BCWP y el coste realizado ACWP. Como dijimos en la sección II,
BCWS era una proyección temporal, y acumulada, del presupuesto del proyecto
desglosado en sus actividades y distribuido en el tiempo. Esto se consigue a partir de la
programación 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 figura es bastante
esclarecedora de lo que acabamos de decir:
Figura A2.7. Programación y costes planificados
Así, el coste planificado BCWS en un momento dado del proyecto es la suma de las
siguientes contribuciones (ver sección II):
 Todas aquellas tareas cuya finalización planificada se haya dado en una fecha
anterior a la fecha de estado dada, contribuirán con todo su coste planificado al
coste planificado acumulado del proyecto.
 Todas aquellas tareas cuyo inicio planificado ocurra en una fecha posterior a la
fecha de estado dada, no contribuirán aun al coste planificado acumulado del
proyecto.
 Todas aquellas tareas que deberían estar en curso en la fecha de estado dada
contribuirán con su fracción de coste planificado según el modelo de
distribución que se haya aplicado.

un CRM.
Tan solo queda, pues, determinar ese modelo de distribución 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 definitiva, hemos podido construir un diagrama de Gantt de todo el
proyecto. Digo esto porque, en mi experiencia, es en este punto donde gran parte de
las organizaciones comienzan a flaquear. El hecho de determinar todas las actividades
a un nivel de detalle equilibrado, junto con todas sus interdependencias y su duración
estimada, es una labor que exige más trabajo, participación y compromisos de todas
las partes implicadas, y una comunicación más fluida, de lo que el nivel de madurez de
muchas organizaciones puede ofrecer, o simplemente están 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ón del valor ganado BCWP, que va a consistir en ir acreditando como
se va alcanzando el valor planificado BCWS. Es por ello que a estos modelos de
distribución también se les suele llamar técnicas de medida del valor ganado. La
esencia de todo esto es que BCWS y BCWP están estrechamente relacionados en
cuanto que el modelo elegido para distribuir el BCWS de cada actividad individual va a
ser la referencia para medir posteriormente como se va ganando ese valor según el
modelo de distribución. La figura siguiente debería clarificar este hecho.
Figura A2.8. Avance en programación y valor ganado

un CRM.
Comparar esta figura con la figura 7, en la que teníamos el coste planificado.

Para todas aquellas tareas que han finalizado, están completamente rellenas de color
rojo, su valor ganado coincidirá con su coste planificado. Esto es así porque una vez
finalizadas 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ás 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 finalizado
aun, que porcentaje llevamos. Sin embargo, hay otras cuyo relleno en rojo no coincide
con el relleno negro planificado. En estos casos el valor ganado BCWP diferirá del coste
planificado BCWS y, cuando se calcule el acumulado, tendremos una curva S (en rojo)
diferente a la planificada (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ás del
previsto, aunque en el cómputo acumulado sale menos trabajo del previsto. Esto es la
esencia de la medición del valor ganado. A continuación abordaremos las diferentes
técnicas para realizar esta medición.
A2.8. Midiendo el Valor Ganado, Segunda Parte
En todo lo que hemos visto hasta ahora sobre el AVG, dos más 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ón del coste de
una tarea o técnicas de medida del valor ganado. Y digo indistintamente porque el
modelo de distribución 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 C, ¿cuando 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 C diarios? De esto estamos hablando cuando nos referimos al modelo de
distribución. Obviamente, como se distribuye ese coste dependerá en gran medida 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 modulo de software compuesto de dos subsistemas tiene un coste estimado de
1.500 €, de los que aproximadamente mil corresponderán 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 aun, no acreditar los 1.500 € hasta
que no se ha finalizado el modulo entero. Después de todo, que significa tener la mitad
del modulo si por sí misma no es nada. Y si se nos apura, ni tan siquiera el modulo por
sí mismo es un producto acabado y lo que realmente tendría valor es la aplicación de
software en su totalidad.

un CRM.
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 ingenuos abogaran
por tener en cuenta todos los detalles para alcanzar la máxima precisión posible,
porque así los resultados serán precisos, etc. Los más resabiados nos aseguraran 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 se ha
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. En
definitiva, 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), aunque 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 cuanto más preciso sea el modelo más exacto 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 entramos dentro de ella para detallar más? Estamos como
siempre, ¿donde empezamos (en pasado) a dejar de ser precisos?, ¿cuán preciso se
puede llegar a ser? Es como esas recetas dietéticas de revista dominical en las que, tras
enumerar la lista de ingredientes (un vaso de aceite -que tipos de vaso tienes en casa
amigo-, dos cucharadas de azúcar - como vas de pulso-, dos o tres unidades de esto o
lo de más allá. . .), nos indica que su contenido calórico es de 95, 6 kilocalorías.. “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! Precisamente, los órdenes de magnitud es otro
de los aspectos que he observado que la gente no suele controlar por esos mundos
empresariales.
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, aun
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. Considero que
estas reflexiones 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 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 que fidelidad refleja ese modelo la parcela de
realidad que pretendemos explicar con él: ahí 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ógica es todo lo que hemos explicado hasta la sección anterior; 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.

un CRM.
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), 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 este 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
ultimo que han escogido los compañeros que han traducido el PMBOK al español. El
termino 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 auditoras
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í? Ahora bien, las matemáticas embutidas sin ton ni
son en un paquete de software por gente que nunca ha sufrido un proyecto, y tan solo
se ha limitado a leerse una manual sobre 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 del modulo de software, en el que
acreditábamos el coste al final de la tarea. Pero también 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 “formula 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 mas, aparte del inicio y fin 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 arrastrara la subjetividad
acerca de con que se ha medido el grado de avance de la tarea.

un CRM.
Al final, de lo que se trata es de escoger aquel que se considere

razonablemente 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 inexactitud. Después de todo,
las posibles inexactitudes 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. Que 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
mas, ¿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 mas 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 nos quite el sueño, amigos.
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. Aunque también se puede optar por 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án escandalizar, aunque para los que vivimos en las trincheras hay
cosas que hace tiempo que dejaron de escandalizarnos.
A2.9. 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 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 PC, y en general de un proyecto, debe ser una
magnitud cuyo recorrido vaya desde 0% (tarea cuyo inicio aun 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 BCWP de dicha tarea
variara entre cero y el coste planificado BCWS 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: BCWP = BCWS. Para el modelo sencillo de “grado
un CRM.
de avance”, el cálculo del valor ganado es:
BCWP = PC × BCWS (8)
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 C, cuando el coste planificado acumulado
para el mismo momento es de 2.000 C. 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 en ese momento 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 C diarios (el coste planificado será de BCWS = 5.000 C), 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 C? 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, por ende, en la línea base y el
BCWS y el BAC). Lo que ha ocurrido en realidad es que vamos con retraso. Vamos a
considerar las dos posibles situaciones:
1. que hemos finalizado en 12 días,
2. que aun no hemos 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 BCWP = BCWS = 5.000 €. Ahora bien, el coste realizado será
de ACWP = 6.000 €. Las desviaciones serán de CV = −1.000€ y SV = 0€
respectivamente.
En el segundo caso aun no se ha finalizado, aunque ya llevamos invertidos dos

días más de los inicialmente presupuestados. ¿Cómo 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ún no hemos finalizado! Realmente necesito una
nueva estimación de lo que 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 C, siendo
BCWP = 4.000 €. Así tenemos que BCWS = 5.000 € (¡en teoría ya debería haber
finalizado!) y ACWP = 6.000€. Las desviaciones son CV = −2.000 € (¡y no mil!) y
SV = −1.000 € (vamos con retraso).

un CRM.
Para finalizar, una figura que ilustra 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.
Figura A2.9. Fecha de estado y avance
La figura A2.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 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: BCWS = 33 C. 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: BCWP = 29 €. La
desviación en programación es (ver formula (1)) SV = BCWP −BCWS = −4 €. El proyecto
en su totalidad va con retraso.
A2.10. El concepto de programación ganada
En la sección VI, donde se trataban los diferentes indicadores para medir la

eficiencia de un proyecto, descubrimos que el índice de eficiencia en programación SPI
y la desviación en programación SV presentaban un comportamiento aparentemente

un CRM.
anómalo en los últimos estadios del proyecto. En efecto, si rescatamos el historial de

desviaciones del ejemplo [3] (ver figura 10), observamos que, mientras la desviación
en coste CV (curva en amarillo) sigue una tendencia decreciente a lo largo del
proyecto, la desviación en programación SV (curva en morado) invierte esa tendencia a
partir 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[3]). Algo similar ocurre con las respectivas eficiencias (ver la
figura 5). En realidad, este hecho no es más que una consecuencia de la definición del
concepto de valor ganado BCWP, magnitud que, por construcción, tiene que coincidir
con el coste planificado BCWS del proyecto en el mismo momento de su finalización,
esto es el BAC. Aunque ello no quita para que perdamos el poder informativo de estas
magnitudes relacionadas con la programación y el plazo. Como anunciamos en su
momento, esto constituya una flaqueza del AVG. Afortunadamente no es un escollo
que no se pueda solventar.
Figura A2.10. Desviaciones en coste y programación
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. Solo 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
un CRM.
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.
Figura A2.11. Concepto de programación ganada
La programación ganada, que denotaremos por ES, no es más que la fecha en la

que el coste planificado acumulado BCWS del proyecto es igual al valor ganado
acumulado BCWP en la fecha de estado AT. Si el proyecto sigue a rajatabla su curso
planificado, estas fechas coincidirán. En caso contrario, no; como se muestra en la
figura 11 para el
caso en que hay retraso.
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 (ver la sección 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ón y eficiencia en programación que
sustituyan a las del AVG. En primer lugar, definimos la desviación en programación SV
(t) como
SV (t) = ES − AT, (9)
mientras que la correspondiente eficiencia como
SPI (t) = ES/AT (10)

un CRM.
Y ya está todo. Ahora tan solo resta determinar cómo se calcula la

programación ganada EV. Pero antes hagamos una pequeña reflexión acerca de la
interpretación de la desviación en programación SV (t), medida en unidades de tiempo
(días, semanas, meses, etc.). ¿Tiene algo que ver esta desviación con la que me darla
un diagrama de Gantt? Si echamos un vistazo a la figura 11, 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 a 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. La desviación en
programación dada por la programación ganada tiene que ver con el esfuerzo. Ofrece
una idea del tiempo que llevara 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ón en plazo que la obtengo a partir de un
diagrama de Gantt, y una desviación en programación que obtenemos a partir del AVG
extendido.
Ahora volvamos al asunto de como calcular la programación ganada ES.

Considerando el ejemplo de la figura 11, la programación ganada debería tener un
valor comprendido entre los meses 5 y 6. Denotemos por x dicha fracción de tiempo,
como se muestra en la figura 12:
Figura A2.12. Cálculo de la programación ganada 1

un CRM.
Las claves para el cálculo las 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 BCWS comprendida
entre los valores BCWS (5) y BCWS (6) es recta. Hay dos consideraciones que podemos
extraer de esto:
1. Esta asunción se aproximara más a la realidad cuanto más pequeña sea la

escala de la dimensión 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 invalidara
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 suele decir que cuanto más
categórico 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álculo. Si ampliamos la zona rodeada por el círculo

verde, tenemos la figura siguiente:
Figura A2.13. Cálculo de la programación ganada

un CRM.
Dado que el triangulo 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 = (BCWP (7) −BCWS (5))/( BCWS(6)−BCWS(5) ). En general, para una programación
ganada ES que se encuentre entre el instante de tiempo n y el n + 1, tendremos que
x = (BCWP(AT)−BCWS(n))/ (BCWS(n+1)−BCWS(n)), con lo que la programación ganada
será:
ES =( n + BCWP(AT) − BCWS(n))/ (BCWS(n + 1) − BCWS(n)) (11)
Y ahora vamos a ver como se utiliza esta traca, que así parece más de lo que es. En el
ejemplo de la tabla de la figura 14 tenemos que
ES = (6 + 4257−4127)/( 5122−4127) = 6,1 meses, según la fórmula (11). Así de simple.
Figura A2.14. Ejemplo
Para completar la exposición retomaremos el ejemplo de la sección VI. En el

siguiente sitio [4] se puede encontrar otro ejemplo en Excel con la actualización del
anterior [3] a la extensión de la programación ganada. A continuación se muestran un
par de figuras extraídas de este último ejemplo, que nos sirve para comentar las
comparaciones entre las antiguas desviación y eficiencia en programación, y las
nuevas. En la figura 15 se muestra el historial de las desviaciones. Esta figura es la
misma que la figura 10, salvo que ahora se incluye la nueva desviación en
programación SV (t) en color azul, medida en meses según la escala vertical de la
derecha.

un CRM.
Figura A2.15. Desviaciones en coste y programación
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 meses, 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 no termine con más retraso aun. Como ya dijimos en su
momento, esto nos da información de la buena. La figura 16 muestra el historial de
eficiencias:

un CRM.
Figura A2.16. Eficiencias en coste y programación
Nuevamente observar las diferencias entre la curva amarilla (la antigua), y la

azul (la nueva). La azul es fiable hasta el final.
El concepto de Programación Ganada se debe a Walt Lipke, quien lo presento

en una publicación [5] en marzo de 2003 cuando estaba al cargo de la división de
software del Centro de Logística Aérea de Oklahoma. Walt Lipke ha desarrollado
asimismo una hoja Excel en el que ha automatizado los cálculos de las diferentes
magnitudes asociadas a la Programación Ganada.
A2.11.Glosario
A continuación se muestra una lista de los términos utilizados con su definición

en ingles y su traducción al español.
 BCWS: Budgeted Cost of Work Scheduled (Coste presupuestado del trabajo

programado).
 BCWP: Budgeted Cost of Work Performed (Coste presupuestado del trabajo

realizado).
 ACWP: Actual Cost of Work Performed (Coste real del trabajo realizado).
 SV: Schedule Variance (Desviación en programación).

un CRM.
 CV : Cost Variance (Desviación en coste).
 SPI: Schedule Performace Index (Índice de eficiencia en programación).
 CPI: Cost Performace Index (Índice de eficiencia en coste).
 EAC: Estimated At Completion (Presupuesto estimado a la finalización).
 ETC: Estimated To Completion (Presupuesto remanente hasta la finalización).
 AT: Actual Time (Tiempo real o fecha de estado).
 ES: Earned Schedule (Programación ganada).
 SV (t): Schedule Variance (Desviación en programación, ver fórmula (9)).
 SPI (t): Schedule Performace Index (Índice de eficiencia en programación, ver

fórmula (10)).

un CRM.

Anexo II. Seguimiento de Proyectos Con El AnÃ¡Lisis Del Valor Ganado

Cargado por

Copyright:

Formatos disponibles

Anexo II. Seguimiento de Proyectos Con El AnÃ¡Lisis Del Valor Ganado

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Anexo II. Seguimiento de Proyectos Con El AnÃ¡Lisis Del Valor Ganado

Cargado por

Copyright:

Formatos disponibles

Seguimiento de proyectos con el Análisis del Valor Ganado Anexo II

Anexo II. Seguimiento de proyectos con el Análisis del Valor

A2.1. El por qué

Vamos a comenzar interrogándonos por su motivación. Consideremos que en

149 Valme Fernández Hueso Ingeniero Industrial

El primer ingrediente que necesitamos, y el más fundamental de todos, es

1. se ha efectuado una programación de todas las actividades del proyecto

Existen múltiples maneras de hacer esto último según la situación concreta

150 Valme Fernández Hueso Ingeniero Industrial

Figura A2.1. Presupuesto y curva S

La curva de color rojo, que representa el coste acumulado del proyecto, se

151 Valme Fernández Hueso Ingeniero Industrial

Si en la sección anterior se hacía especial hincapié en el presupuesto

Todo sistema de medida requiere de unas magnitudes cuantitativas y unas

El valor ganado es una magnitud crucial para nuestro análisis, no en balde de

152 Valme Fernández Hueso Ingeniero Industrial

SV = BCWP − BCWS, (1)

Donde BCWP es el valor ganado, BCWS el coste planificado y SV, al que

CV = BCWP − ACWP, (2)

Donde ACWP es el coste realizado y CV la desviación en coste. Si la desviación

153 Valme Fernández Hueso Ingeniero Industrial

Figura A2.2. Curva S, costes planificado, real y valor ganado

Mediante una aritmética extremadamente sencilla, hemos derivado dos

¿Qué ocurriría si esta tendencia de desviarse del plan previsto continúa a lo

154 Valme Fernández Hueso Ingeniero Industrial

estaba constituido por las desviaciones en coste y programación). Como se adelantaba

¿Cómo construir esta nueva magnitud? Pues mediante la cuenta de la vieja.

Hechas estas consideraciones, volvamos con el segundo grupo de magnitudes

VAC = BAC – EAC (4)

155 Valme Fernández Hueso Ingeniero Industrial

ETC = EAC – ACWP (5)

Veamos todo esto en la representación de las curvas S (ver Figura 3):

Figura A2.3. Curva S y extrapolaciones

Las líneas punteadas no se corresponden con datos reales sino con

156 Valme Fernández Hueso Ingeniero Industrial

Hemos definido tres grupos de magnitudes, de los que solamente el primero es

• Primer grupo: magnitudes que se hallan directamente

• Segundo grupo: desviaciones calculadas a partir de los valores de las magnitudes

• Tercer grupo: predicciones sobre la finalización del proyecto calculadas a partir de

Viendo el AVG como un proceso, la figura siguiente ilustra el diagrama de dicho

Figura A2.4 Proceso AVG

157 Valme Fernández Hueso Ingeniero Industrial

Aunque el diagrama no es completo, aun faltan más productos de salida que

 En primer lugar, aunque el diagrama no sea completo en su parte derecha, sí lo

• El proceso es pura, y extremadamente simple, algoritmia. Y como tal, puede ser

Precisamente debido a su sencillez, se puede implementar de forma simple en

158 Valme Fernández Hueso Ingeniero Industrial

A2.6. Índices de eficiencia

Imaginemos al gerente de una unidad de negocio estudiando los informes de

Necesitamos pues de otras que si lo hagan realmente. Y as entramos en un

159 Valme Fernández Hueso Ingeniero Industrial

haremos una división. La magnitud clave es el valor ganado BCWP. Si la referencia es el

CPI = BCWP/ACWP, (6)

SPI = BCWP/BCWS, (7)

En ambos casos tendremos que la eficiencia es 0 si no se ha hecho nada y 1 si

Con este cuarto grupo de magnitudes cerramos el tema de los indicadores. En

Figura A2.5. Eficiencias en coste y programación

160 Valme Fernández Hueso Ingeniero Industrial

En color amarillo tenemos la evolución de la eficiencia en programación. Vemos