Es una gran satisfacción para mí anunciar que la tercera conferencia anual de Análisis del Valor Ganado (AVG) para Europa se celebrará este año en Valencia.
Después de las dos exitosas conferencias celebradas en el CERN (Suiza) en 2009, y en Gante (Bélgica) en 2010, gracias a Rafael Sánchez, director de la ETS Ingeniería de Edificación de la Universitat Politècnica de València, y a Eduardo Bolufer, profesor de dicha escuela, este año se celebrará durante los días 23 y 24 de noviembre en la Universitat Politècnica de València.
Aunque el objeto principal de la conferencia es el AVG, la temática está abierta al resto de áreas en Project Management. En concreto, las áreas de la conferencia de este año son las que muestro al final de esta entrada.
La conferencia consta de dos sesiones en paralelo, una académica y otra profesional. Animo a cualquiera de vosotros que tiene por ahí guardado aquello tan interesante para contar que dé el siguiente paso y presente su propuesta para hablar en la conferencia. O, aunque no tengáis nada listo, simplemente participar.
Por otro lado, si alguna compañía u organización está leyendo esto, también les animo a participar y contar su experiencia en la conferencia ante un público proveniente de toda Europa. Les invito también a patrocinar el evento.
Podéis obtener más información en el sitio Web de la conferencia.
Áreas temáticas de la conferencia:
Algorithmic design for project scheduling and monitoring
Methodologies for project monitoring
Methodologies for project performance measurement
Methodologies for Earned Value Management
Integration studies between risk analysis and project monitoring
Successful cases of project management and monitoring
En el principio fue el proyecto. Y luego vinieron las operaciones.
Desde un punto de vista operativo –signifíquese como sinónimo de acción, y no de operacional o relativo a la Dirección de Operaciones-, es un hecho que la primera actividad de envergadura que emprendió la humanidad fue un proyecto –al menos por aquello de realizar algo que no se había acometido antes-. Luego, bastante más tarde, llegó la producción en serie y las tareas repetitivas. Es decir, las operaciones. Esta nueva actividad cobrará su máxima dimensión con la Revolución Industrial y, sobretodo, con el advenimiento de la sociedad de consumo –un consumo masivo que justifica la producción en serie y continuada.
Sin embargo, desde un punto de vista directivo –managerial, cuánto echo de menos un adjetivo en castellano para gestión-, la realidad es que en un principio fueron las operaciones y luego vino el proyecto. Y si no, hablad con un consultor en Dirección de Proyectos, si es que esa cosa existe o está reconocida… Con un jefe de proyecto en activo, permitidme la duda, la conversación ya no sería tan clara, pues aunque sí podríamos llegar a una distinción operativa –en la acción- entre proyecto y operaciones, quizás legáramos tarde o temprano a descubrir que lo dirige, más o menos, matiz aquí o allá, como si estuviera dirigiendo operaciones. Volviendo a la línea inicial de este párrafo, la primera racionalización directiva de un proceso de negocio que se efectuó en la historia tuvo lugar en el mundo de las operaciones, bien porque éstas devinieron en negocios prósperos, bien porque son más sencillas de racionalizar que un proyecto, o bien por cualquier combinación de las dos junto con otros factores. El hecho es que el primer enfoque racional, sistémico y sistemático en la gestión y la dirección nace a finales del siglo XIX con el trabajo de Frederick W. Taylor, “Los principios de la gestión científica” –lo de “científica” quizás queda algo rimbombante, pero es muy representativo de la época, tan decimonónica-. Y se aplicó a la producción en masa, a las operaciones.
Y nos vamos ya a los años 50 y 60 del pasado siglo para encontrarnos con las primeras técnicas pensadas especialmente para los proyectos, como el CPM, el PERT y el AVG. Para el modelado de una filosofía de gestión y el desarrollo de una metodología y forma de organización propia, incluso más tarde. Y para que sea una moda, menos de 20 años ha. Pero para entonces, la Dirección de Operaciones ya era una disciplina muy poderosa, ampliamente aceptada y profundamente asentada en las organizaciones. De hecho, no es extraño encontrar aún la gestión de proyectos como un área de la Dirección de Operaciones –como muestra, el enlace anterior al que lleva PERT-. Todo esto creo que hace que, aunque hoy en día se habla mucho de proyectos, lo que uno encuentra por detrás, a poco que rasque, es una filosofía de operaciones –de hecho, creo que una de las razones principales del fracaso en proyectos se debe a ello: la aplicación de unas técnicas y herramientas, y una filosofía, fuera de su contexto y en otro diferente en el que su validez es poco menos que dudosa-.
Vamos a ver algunas de las diferencias cruciales mediante unos ejemplos de juguete, cortesía de LEGO. En primer lugar, veamos el siguiente video:
Una línea de ensamblado de cochecitos hechos con piezas de LEGO, hecha también con piezas de LEGO. Pero lo que nos interesa es la propia línea de ensamble como todo un arquetipo de lo que representan las operaciones. Sirve para producir de forma masiva un producto. Posee una forma de programar el trabajo y acopiar materiales muy específicos que nada tiene que ver con la forma en que se hace en un proyecto. Se realizan tareas repetitivas y continuadas, mientras que en un proyecto son únicas y discontinuas. El objetivo de la línea es mantener un negocio, el del trueque de cochecitos LEGO con otros niños a cambio de piruletas, digamos, mientras que el de un proyecto es el de alcanzar los suyos propios y finalizar –el propio diseño y construcción de la línea de ensamble sí es un proyecto, que finaliza cuando está lista para entrar en producción-. En cambio, cuando las operaciones alcanzan sus objetivos –venta de tantas unidades de cierto modelo-, adquieren unos nuevos –producción de tantas otras unidades de otro modelo-. Para ello, la organización ejecutará un proyecto consistente en la modificación de la línea para las nuevas necesidades o su sustitución por otra nueva.
La organización de los recursos humanos también será diferente, pues su uso en el trabajo en la línea de ensamble puede ser más continuado que en el trabajo en tareas discontinuas en uno o varios proyectos; los problemas de asignación son diferentes. El acopio de materiales también es diferente: en la planta necesito muchas unidades de un mismo tipo de material, que puedo organizar en estocajes e inventarios de los que se alimenta la línea sin importar el orden de recepción, pues las unidades son indistintas. En cambio, en un proyecto no es habitual disponer de más de una unidad de cierto tipo de material, y aunque se necesite de más de una son pocas y no muchas como en el caso de la línea de ensamble, y aunque haya mas dos o más unidades iguales no se pueden organizar como un estocaje pues no son requeridas de forma continuada sino discontinua en diferentes y separados instantes de tiempo. Es decir, aunque haya unidades iguales de material, en la práctica son distinguibles. En realidad, el concepto de inventario, crucial en las operaciones, no tiene sentido en un proyecto.
La calidad, al menos cuantitativamente, es un concepto estadístico de gran utilidad natural en las operaciones: producir un gran número de unidades permite definir estándares de calidad como valores medios. Un proyecto tiene como resultado un producto único –hoy en día también servicios, por lo que siempre que nos refiramos a producto debemos considerar también servicio-, por lo que no tiene sentido hablar en términos estadísticos. Se puede, y se debe, gestionar la calidad, pero desde luego no extrapolando las técnicas utilizadas en operaciones.
Creo que todas estas diferencias son bastante evidentes. A pesar de ello, no es extraño encontrar una organización que fabrica, digamos, líneas de ensamble como la del video –pero para coches de verdad- y que está organizada como si fuera a producir en masa un gran número de ellas exactamente iguales, como si fueran un mismo modelo de coche. Las operaciones pesan mucho –de hecho, el equipo gestor tendrá una formación en Dirección de Operaciones- y la inercia es inexorable. Sin embargo, así como un fabricante de coches está orientado a operaciones, un fabricante de líneas de ensamble, todas ellas variopintas, debería estar orientado a proyectos. Poco a poco.
Veamos un último ejemplo. El de la siguiente imagen:
Imágenes de este tipo aún se utilizan para ilustrar el WBS (Desglose Estructurado del Trabajo) de un proyecto. Desafortunadamente, el trabajo no se ve por ningún lado en la imagen: sólo una relación de piezas de algo. Bueno, de lo siguiente:
En realidad, la primera imagen es un ejemplo de BOM (Bill of Materials), un concepto proveniente de las operaciones que suele deslizarse en el mundo de los proyectos y rebautizado como WBS. En el video anterior, el BOM sería la lista de todas las piezas necesarias para que la línea ensamble el producto final. Luego, mediante un MRP, otro concepto proveniente de las operaciones, se calculan las necesidades de acopio de materiales y estocaje de inventario según la programación de la línea de ensamble. Por tanto, teniendo en cuenta lo discutido cuatro párrafos antes, habría que reflexionar acerca de si un MRP es realmente una buena forma de planificar la producción de líneas de ensamble.
El WBS es más que un BOM. Es el resultado del último proceso a realizar durante la planificación del alcance de un proyecto, en el que se ha detallado todo el trabajo que se ha de realizar, y solamente el que se ha de realizar, para la creación de los resultados del proyecto. El PMBOK sugiere una clasificación intermedia entre “Alcance Producto”, que define como “las características y funciones que caracterizan a un producto, servicio o resultado” –el equivalente al BOM de las operaciones-, y “Alcance Proyecto”, que define como el “trabajo que debe realizarse para entregar un producto, servicio o resultado con las funciones y características especificadas” –que se manifiesta de forma explícita con el WBS-. Para el producto de las imágenes anteriores, el WBS podría contener ítems como los siguientes: comprar pieza 6, pintar de rojo pieza 8, unir lateralmente las piezas 6 y 11, celebrar reunión de seguimiento, documentar la fase 2 del proyecto, reunirse con el cliente, preparar informe de progreso, etc.
Moraleja: no es lo mismo gestionar un proyecto que gestionar por proyecto. Lo primero ya lo hace casi todo el mundo como buenamente puede. Lo segundo... estamos en ello.
Novedades 16/01/14: Una nueva versión que funciona con Microsoft Project Professional 2013 ya se puede descargar desde aquí.
Novedades 11/03/11: La versión MSP 2007 de la nota anterior también funciona con MSP 2010.
Novedades 27/02/09: Una nueva versión que funciona con MSP 2007 ya se puede descargar desde aquí.
Novedades 14/06/07: la primera versión se ha sustituido por una nueva en la que se ha corregido un error de cálculo.
La técnica de la Programación Ganada (ES de su acrónimo en inglés) es una extensión del Análisis del Valor Ganado (AVG) que ha sido reconocida recientemente como una práctica emergente por el Project Management Institute (PMI). Este enfoque novedoso se basa en el potente concepto de Programación Ganada (PG) introducido por Walt Lipke en su artículo pionero “Schedule is Different”. La razón que dio lugar a esta extensión fue el hecho bien conocido de que, en algunos escenarios concretos, algunos indicadores del AVG, como la desviación en programación SV y el índice de eficiencia en coste SPI, se comportan de forma inesperada a partir de cierto momento hacia el final de un proyecto, perdiendo todo su poder predictivo. Para conocer más sobre esta técnica ver la documentación de dominio público que se encuentra en Earned Schedule. Dado que es una práctica muy reciente, hasta donde sé los principales paquetes de software sobre programación de proyectos aún no la incorporan. El propio Lipke ha puesto a disposición una hoja de cálculo para automatizar el cálculo de la PG partiendo del coste planificado BCWS y del valor ganado BCWP.
Quiero mostrar aquí una macro realizada en VBA para MS Project (MSP) que prepara informes mensuales en Excel de los indicadores del AVG y de la PG con el propósito de que pueda ser útil para proyectos de pequeña y mediana entidad cuya programación se lleva con MSP. Y solamente su programación, es decir que el coste se lleva a parte –práctica nada extraña por otro lado. El tipo de proyecto para el que se utiliza la macro es aquél compuesto por actividades desempeñadas por recursos del tipo de mano de obra, en la que su duración se puede condicionar a su esfuerzo. De esta forma, tanto el coste como su duración son proporcionales al esfuerzo, horas-hombre por ejemplo. De esta manera, con seguir las horas es suficiente. Por mi experiencia, la tipología propia de estos proyectos unida a la inmadurez relativa de las organizaciones que suelen desempeñarlos hacen que efectuar un seguimiento del coste, además de la programación, sea con bastante frecuencia una empresa infructuosa. Otro inconveniente de MSP es que posee una implementación del AVG muy pobre, ya que no permite llevar un seguimiento histórico de las curvas S para los costes BCWS, BCWP, ACWP y sus magnitudes derivadas, y por tanto tampoco permite mostrar una representación gráfica de las mismas. Por otro lado, como adelantaba al principio, no incorpora la PG.
En el siguiente archivo de MSP, versión 2003, se puede encontrar un ejemplo del funcionamiento de la macro. Si el fichero se va a abrir con una versión diferente saldrá un mensaje de error y habrá que seleccionar las librerías adecuadas desde el menú del editor de Visual Basic de MSP: Herramientas-->Preferencias. Estas librerías son "Microsoft Project xx.x Object Library" and "Microsoft Excel xx.x Object Library", donde xx.x es la versión correspondiente a la versión de MSP -11.0 para MSP 2003. No olvidar tampoco comprobar el nivel de seguridad de macros de manera que permita su ejecución. Una vez abierto el archivo, aparecerá un nuevo menú llamado “Reports” en la barra de menús. Pinchando sobre el mismo se obtiene el informe en Excel del proyecto. El archivo contiene un ejemplo de proyecto con una duración de 18 meses que se ha actualizado de forma mensual seis veces desde su inicio. Para que el informe se pueda generar, debe haberse guardado una línea base con la planificación inicial del proyecto, y asignar una fecha de estado adecuada. Cada vez que se genera un informe mensual, el archivo va guardando estos datos de forma que va creando un histórico mensual de los indicadores que aparece actualizado cada vez que se genera el informe en Excel, pudiendo así descartar los informes generados con anterioridad. De esta manera, el informe muestra de forma gráfica la evolución de las curvas S y el resto de indicadores. Las magnitudes de tipo coste están medidas en horas-hombre y las de tiempo en semanas o días.
Llevaba largo tiempo pensando en recoger y unificar bajo un mismo formato todo aquello que he ido contando en esta serie acerca del seguimiento de proyectos con el Análisis del Valor Ganado (AVG). Esta visión se ha visto finalmente materializada en este documento, cuya culminación ha sido más ardua de lo que un refrito de textos podía suponer a priori. Para ello he tenido que revisar, corregir erratas y estilo, además de entrelazar las diversas partes del documento que, pese a provenir de una serie más o menos homogénea, nunca lo puede ser dado el carácter discontinuo y espaciado en el tiempo de los diferentes fragmentos. Releyendo sentía a veces que me hubiera acechado el peligro que narraba Montaigne de que hubiera perdurado el recuerdo de las cosas pasadas habiendo perdido el recuerdo de sus repeticiones. Espero haber salido indemne de él.
Por otro lado, he optado por volver a los orígenes, por lo que a notación se refiere, y reescribir todas las magnitudes del AVG en su versión estándar y tradicional. Al final he añadido un glosario con las definiciones originales en inglés de estas magnitudes y su traducción española. El artículo, al igual que esta serie, finaliza con una introducción a la Programación Ganada (PG), una técnica de muy reciente aparición en la disciplina de la Dirección de Proyectos. Obviamente, se puede profundizar más en PG –al igual que en AVG-, pero he preferido cerrar esta serie –y el artículo- con el alcance que se ha configurado a lo largo de la misma ya que le confiere un todo coherente y un nivel más que suficiente para su aplicación al seguimiento de proyectos. Ello no quiere decir que sigamos ahondando en ello, sólo que con esto cerramos una etapa.
En el sexto anuncio de la serie del Análisis del Valor Ganado (AVG), en el que se abordaban los diferentes indicadores para medir la eficiencia de un proyecto, descubrimos que el índice de eficiencia en programación EP -y la desviación en programación DP- presentaban un comportamiento aparentemente anómalo en los últimos estadios del proyecto. En efecto, si rescatamos el historial de desviaciones del ejemplo que se proporcionaba en aquel anuncio, observamos que, mientras la desviación en coste DC sigue una tendencia decreciente a lo largo del proyecto, la desviación en programación invierte esa tendencia a partir de de la semana 20, más o menos.
Parece como si el proyecto se hubiera recuperado en plazo y finalmente hubiera terminado en el plazo previsto, cuando en realidad ha finalizado dos meses más tarde –ver el ejemplo. Algo similar ocurre con las respectivas eficiencias. En realidad, este hecho no es más que una consecuencia de la definición del concepto de valor ganado VG, magnitud que, por construcción, tiene que coincidir con el coste planificado CP del proyecto en el mismo momento de su finalización. Aunque ello no quita para que perdamos el poder informativo de estas magnitudes relacionadas con el plazo. Como anunciamos en su momento, esto constituía una flaqueza del AVG. Afortunadamente no es un escollo que no se pueda solventar.
Hay que resaltar que esta flaqueza no quiere decir para nada que el valor ganado sea un mal concepto. Todo lo contrario. Es uno de los últimos conceptos más importantes que se han aportado a la disciplina de la dirección de proyectos. Sólo el hecho de permitir obtener desviaciones en coste realistas frente a las malas prácticas, aunque muy extendidas, de medirlas respecto al presupuesto inicial, ya es un gran avance en sí mismo. Lo único es que hemos encontrado que tiene sus limitaciones a la hora de tratar la programación. Unas limitaciones que se pueden superar extendiendo el método. Y aquí es donde entra el concepto de Programación Ganada. En realidad, es una idea análoga a la del valor ganado, aunque en vez de utilizar unidades monetarias para medir desviaciones y eficiencias de programación se utilizan unidades de tiempo. El concepto de programación ganada, como todos los que hemos visto del AVG, es extremadamente simple e intuitivo. La programación ganada, que denotaremos por PG, no es más que la fecha en la que el coste planificado acumulado CP del proyecto es igual al valor ganado acumulado VG en la fecha de estado FE. Si el proyecto sigue a rajatabla su curso planificado, estas fechas coincidirán. En caso contrario, no; como se muestra en la figura siguiente:
Es importante resaltar que la introducción de esta nueva magnitud no supone incrementar el número de magnitudes que se miden directamente, ya que se mide a partir de otras. Es una magnitud derivada. Esto es muy bueno porque lo realmente complicado en el AVG es obtener medidas directas. A partir de esta magnitud podemos obtener unas nuevas desviación y eficiencia en programación que sustituyan a las del AVG. En primer lugar definimos la desviación en programación DPt como DPt = PG-FE, mientras que la correspondiente eficiencia como ECt = PG / FE. Y ya está todo. Ahora tan sólo resta determinar cómo se calcula la programación ganada PG. Pero antes hagamos una pequeña reflexión acerca de la interpretación de la desviación en programación DPt, medida en unidades de tiempo –días, semanas, meses, etc. ¿Tiene algo que ver esta desviación con la que me daría un diagrama de Gantt? Si echamos un vistazo a la figura anterior, vemos que la desviación se calcula a partir de la diferencia entre valores acumulados del coste planificado y el valor ganado. Valores acumulados. En cambio, en un diagrama de Gantt, una desviación en plazo de, digamos, una semana se puede deber tanto a que una tarea posee una desviación de una semana como que cinco tareas en paralelo posean todas ellas una desviación de una semana. Aunque la desviación es de una semana en ambos casos, a nadie se le escapa que el segundo caso es más difícil de recuperar que el primero, debido ha que hay más trabajo sin hacer. Esto no es más que una manifestación de la diferencia que hay entre esfuerzo y duración. Pues la desviación en programación dada por la programación ganada refleja precisamente este último caso. Ofrece una idea del tiempo que llevaría recuperar todo el trabajo no realizado hasta la fecha, independientemente de los plazos. Hay que reconocer que el concepto no deja de ser potente. Imagínese que le comunican que lleva un día de retraso en el plazo del proyecto, pero que supone un esfuerzo de dos semanas recuperar ese plazo. Así pues no hay que confundir una desviación en plazo que la obtengo a partir de un diagrama de Gantt, y una desviación en programación –el término más que nada para distinguir- que obtengo a partir del AVG extendido.
Ahora volvamos al asunto de cómo calcular la programación ganada PG. Considerando el ejemplo de la figura anterior, la programación ganada debería tener un valor comprendido entre los meses 5 y 6. Denotemos por x a esta fracción, como se muestra en la siguiente figura:
Las claves para el cálculo los encontramos en el área delimitada por el círculo verde. Y ahora es cuando viene la aproximación –a estas alturas ya deberíamos estar acostumbrados a ello :-). Vamos a considerar que la porción de curva CP comprendida entre los valores CP(5) y CP(6) es recta. Hay dos conclusiones que podemos extraer de esto:
Esta asunción se aproximará más a la realidad cuanto más pequeña sea la escala de la dimensión temporal –el eje horizontal; esto es, semanas mejor que meses, mese mejor que trimestres, etc. Pero que no nos ciegue esto; no hay que olvidar que siempre hay un límite en el que el ruido del entorno invalidará cualquier efecto producido por ser más preciso.
Hay que desconfiar de aquellos que emiten juicios categóricos del tipo “la lógica matemática demuestra que…”. La matemática dirá lo que tenga que decir en su contexto. En el que nos manejamos nosotros sería más conveniente un juicio del tipo “los siguientes resultados ofrecen una desviación bastante aproximada por la razón que…”. La experiencia me dice que cuanto más categórico es un argumento, menor es la idea que tiene sobre el asunto el que argumenta.
Pero continuemos con el cálculo. Si ampliamos la zona rodeada por el círculo verde, tenemos la figura siguiente:
Dado que el triángulo pequeño y el grande están a escala entre ellos, por relaciones de semejanza obtenemos el valor de la fracción x. A saber x = [VG(7) – CP(5)] / [CP(6) – CP(5)]. En general, para una programación ganada PG que se encuentre entre el instante n y el n+1, tendremos que x = [VG(FE) – CP(n)] / [CP(n+1) – CP(n)], con lo que la programación ganada será PG = n + [VG(FE) – CP(n)] / [CP(n+1) – CP(n)]. Y ahora vamos a ver cómo se utiliza esta traca, que así parece más de lo que es. En el ejemplo de la tabla siguiente tenemos que PG = 6 + (4257-4127) / (5122-4127) = 6,1 meses. Así de simple.
Para completar la exposición retomaremos el ejemplo del libro de Excel que se ofrecía en el sexto anuncio. Pero antes los créditos. El concepto de Valor Ganado se debe a Walt Lipke, quien lo presentó en una publicación en marzo de 2003 cuando estaba al cargo de la división de software del Centro de Logística Aérea de Oklahoma. La técnica de análisis ha sido posteriormente desarrollada conjuntamente con Kym Henderson, director de educación del capítulo de Sydney del PMI. Walt Lipke ha desarrollado asimismo un libro de Excel en el que ha automatizado los cálculos de las diferentes magnitudes asociadas a la Programación Ganada. Podéis descargarla desde este sitio en su versión original en inglés o desde aquí en español. Quiero agradecer a Walt Lipke y Kym Henderson el permiso para traducir al español la hoja de cálculo de la Programación Ganada y distribuirla entre la comunidad de habla española.
Vamos ya con el ejemplo. En el siguiente libro de trabajo de Excel se puede encontrar la plantilla del AVG actualizada con la extensión de la programación ganada. A continuación muestro un par de figuras extraídas del ejemplo para comentar las comparaciones entre las antiguas desviación y eficiencia en programación y las nuevas. En la primera figura se muestra el historial de las desviaciones. La figura es la misma que abría este anuncio salvo que ahora se incluye la nueva desviación en programación DPt en color azul –¡ojo ahora medida en meses según la escala vertical de la derecha!
Podemos comprobar que este indicador sí que proporciona buena información hasta el final del proyecto, a diferencia del anterior –en color amarillo. Al final del proyecto, la desviación es de dos mese, justo el retraso que ha tenido el proyecto. También se puede ver como hacia el final del proyecto se hace un esfuerzo para recuperar plazo y que el proyecto no termine con más retraso aún. Como ya dijimos en su momento, esto nos da información de la buena. La siguiente y última figura muestra el historial de eficiencias:
Nuevamente observar las diferencias entre la curva amarilla, la antigua, y la azul, la nueva. La azul es fiable hasta el final.
¿Puede tener una tarea un grado de avance del 120%? Como poder todo depende de lo que queramos entender por grado de avance. Hablando en términos de valor ganado, ¿puede una tarea haber ganado mayor valor que su coste presupuestado? Análogamente al ejemplo anterior, dependerá de lo que entendamos por valor ganado. Según el criterio asumido por al Análisis del Valor Ganado (AVG), las preguntas formuladas anteriormente tendrían la misma respuesta que esta: ¿se puede llenar con litro y medio de agua una botella de un litro?
El grado de avance de una tarea (GA), y en general de un proyecto, debe ser una magnitud cuyo recorrido vaya desde 0% (tarea cuyo inicio aún no se ha acreditado, ojo que esto no significa que no se haya iniciado) a 100% (acreditación de que se han alcanzado sus resultados). De la misma manera, el valor ganado VG de dicha tarea variará entre cero y el coste planificado CP para la misma. Cuando una tarea se da por finalizada, se asume que su grado de avance es del 100% y se ha ganado todo el valor inicialmente presupuestado: VG=CP. Para el modelo sencillo de “grado de avance”, el cálculo del valor ganado es VG=GRxCP. Otra cosa muy distinta es que en un momento dado el grado de avance que, según la planificación, debería ser del 20%, sea del 25%. O que el valor ganado acumulado hasta ese momento sea de 2.500 €, cuando el coste planificado acumulado para el mismo momento es de 2.000 €. Todo ello indica que vamos adelantados en programación. Pero, independientemente de que finalicemos la tarea (o proyecto) con antelación o retraso, nos hayamos gastado más o menos de lo presupuestado, siempre ocurrirá que el grado de avance es del 100% y el valor ganado será igual al coste planificado. No hay ninguna razón extraña y oculta para ello, simplemente se debe a nuestra definición de los conceptos de grado de avance y valor ganado.
Pero resulta que el cableado de fibra óptica de cierta área estaba estimado en 10 días a razón de 500 € diarios (el coste planificado será de CP = 5.000 €), y en cierto momento se nos dice que se han imputado ya 12 días. ¿Qué está ocurriendo? ¿Llevamos un grado de avance del 120%? ¿Un valor ganado de 6.000 €? Obviamente se han invertido dos días más de los inicialmente previstos, pero eso no quiere decir que le hemos cogido gusto a eso de cablear y nos hemos salido del área inicialmente prevista (este caso supondría un cambio en el alcance y sobre ello hablaremos en un futuro). Lo que ha ocurrido en realidad es que vamos con retraso. Vamos a considerar las dos posibles situaciones: (1) que he finalizado en 12 días; (2) que aún no he finalizado. En el primer caso he finalizado en 12 días, por lo que el grado de avance será del 100% y el valor ganado VG=CP = 5.000 €. Ahora bien el coste realizado será de CR = 6.000€. Las desviaciones serán de DC = -1.000 € y DP = 0 € respectivamente.
En el segundo caso aún no he finalizado, aunque ya llevo invertidos dos días más de los inicialmente presupuestados. ¿Cómo calculo el grado de avance? La referencia inicial ya no me vale porque la he sobrepasado, eso me daría un grado de avance irreal del 120%, ¡cuando aún no he finalizado! Realmente necesito una nueva estimación de lo que me resta para finalizar. Bien, llevamos 12 días, ¿cuántos estimamos que nos quedan para finalizar? Supongamos que son 3 días, eso quiere decir que la nueva duración estimada es de 15 días. El grado de avance será entonces de 12/15 = 80%, esto sí que tiene sentido. Y ahora viene el cálculo clave que nos hará comprender en toda su amplitud el concepto de valor ganado. El valor ganado será el 80% del coste inicialmente presupuestado de la tarea, que era de 5.000 €, VG = 4.000 €. Así tenemos que CP = 5.000 € (¡en teoría ya debería haber finalizado!) y CR = 6.000 €. Las desviaciones son DC = -2.000 € (¡y no mil!) y DP = -1.000 € (vamos con retraso).
Para finalizar, una figura que espero que ilustre de forma simple la relación entre los conceptos de coste planificado, valor ganado y modelos de distribuir el coste planificado en el tiempo y medir el valor ganado.
La figura representa un diagrama de Gantt en el que las barras horizontales son las tareas. La línea vertical de color azul representa la fecha de estado del proyecto. El color negro de las barras de tarea representa la planificación, mientras que el rojo representa lo que se ha hecho hasta la fecha representada por la línea azul. El modelo de distribución es el siguiente: cada cuadradito de la rejilla que ocupan las barras de tarea representa un euro. Así pues, el coste planificado acumulado hasta la fecha marcada por la línea azul vendrá dado por la suma de todos los cuadraditos, tanto negros como rojos (notar que en planificación son todos negros) que estén situados a la izquierda de la línea azul. Son 33 cuadraditos: CP = 33 €. Eso es todo lo que se debería haber hecho según lo planificado. El valor ganado es todo lo que se ha hecho hasta la fecha y vendrá dado por la suma de todos los cuadraditos de color rojo, tanto si están a la izquierda como a la derecha de la línea azul. Notar que en algunas tareas puedo ir retrasado y en otras adelantado. Son 29 cuadraditos: VG = 29 €. La desviación en programación es DP = VG – CP = -4 €, el proyecto en su totalidad va con retraso.
Los lectores que hayan leído sobre el Análisis del Valor Ganado (AVG) y/o lo hayan utilizado, ya habrán notado que la notación que he utilizado referente a las magnitudes que se han ido definiendo no es la que se suele utilizar en la literatura, tanto en textos originales en inglés como en español. En realidad he optado, no sé si con fortuna o no, en definir una nueva notación utilizando tan sólo dos letras que, de alguna manera, hagan de acrónimo del nombre que he dado a las magnitudes. Nombre que, aunque simplificado, si que coincide con las verdaderas magnitudes de siempre del AVG.
En mi opinión, la notación que se ha venido utilizando tampoco es que sea una maravilla, por lo que, dado que la aproximación que he hecho a lo largo de los anuncios de esta serie ha sido, o al menos lo he intentado, de autodescubrimiento progresivo sobre lo que estábamos haciendo en cada momento, me he permitido la licencia de rebautizar los símbolos que representan las diferentes magnitudes, siempre con el fin de reflejar el concepto que representan. Espero que para aquellos lectores que ya están en contacto con el AVG, o que vayan a profundizar los conocimientos adquiridos en otros textos de la literatura, la notación no estándar que he utilizado no constituya un quebradero de cabeza adicional. Con el fin de remediar, o simplemente suavizar, este aspecto, añado una tabla con las equivalencias entre la notación que he utilizado y las más estándares de la literatura o paquetes de software populares.
Finalmente, para quien quiera profundizar en el tema puede hacerlo en los siguientes títulos:
J. Davidson Frame, La nueva dirección de proyectos. Este está traducido al español y utiliza una notación muy similar a la de la traducción del MSPoject®.
Por último un par de títulos dedicados exclusivamente al AVG: Q. W. Fleming & J. M. Koppelman, Earned Value Project Management, y PMI, Practice Standard for Earned Value Management. Este último, de reciente publicación, es el estándar oficial del PMI y define su propia notación, aunque no difiere mucho de la tradicional.
La verdad, es que este ha sido el anuncio de la serie que más me ha costado escribir. En todo lo que hemos visto hasta ahora en esta serie sobre el Análisis del Valor Ganado (AVG), dos más dos solían ser cuatro. En lo que viene a partir de ahora, es difícil asegurarlo. Vamos a acabar lo que comenzamos en el anuncio anterior. Vamos a ocuparnos de lo que indistintamente nos hemos referido como modelos de distribución del coste de una tarea o técnicas de medida del valor ganado. Y digo indistintamente porque el modelo que escojamos va a ser la referencia para la posterior medición del valor ganado.
Si tenemos una tarea de dos semanas de duración (10 días laborables) con un coste asociado de 3.500 €, ¿cuándo decimos que se hace efectivo dicho coste? ¿Al inicio de la tarea?, ¿a su finalización? ¿O acaso se reparte uniformemente a razón de 350 € diarios? De esto estamos hablando cuando nos referimos al modelo de distribución. Obviamente, cómo se distribuye ese coste dependerá en gran manera de la propia estructura intrínseca de la tarea, y en menor manera (o mayor, por qué no) de cómo nos interesa que se haga esa distribución. Y me explico. La programación de cierto módulo de software compuesto de dos subsistemas tiene un coste estimado de 1.500 €, de los que aproximadamente mil corresponderían a un subsistema y los restantes quinientos al otro subsistema. Si a su vez hemos estimado el número de líneas de código que contiene cada uno de los subsistemas, podríamos prorratear las cantidades entre el número de líneas de código e ir acreditando posteriormente el coste según vamos teniendo líneas de código; o no acreditar nada hasta que no se ha finalizado cada uno de los módulos; o, más sencillo aún, no acreditar los 1.500 € hasta que no se ha finalizado el módulo entero, después de todo qué significa tener la mitad del módulo si por sí misma no es nada. Y si se me apura, ni tan siquiera el módulo por sí mismo es un producto acabado y lo que realmente tendría valor es la aplicación de software en su totalidad.
Si reunimos a varias personas tendremos opiniones para todos los gustos, y todas ellas justificadas en mayor o menor medida con razonamientos más o menos técnicos, sacados de lo que dicta la experiencia diaria, etc. Los más académicos abogarán por tener en cuenta todos los detalles para alcanzar la máxima precisión posible, porque así los resultados serán precisos, and so on. Los más resabiados nos asegurarán que es una empresa quijotesca y que no hay nada mejor que ir respondiendo sobre la marcha a las inevitables circunstancias del día a día. El lector podrá apreciar que he abierto una caja de Pandora, y mucho me temo que soy incapaz de cerrarla. Es más, me asusta mucho cuando alguien viene diciendo que es capaz de cerrarla, que tiene la solución. Mi conclusión personal es que no existen razones definitivas que justifiquen completamente un modelo concreto en un determinado contexto –algunos compañeros del PMI o defensores a ultranza del PMBOK no estarán de acuerdo conmigo; y no hay nada como la experiencia sensata para matizar lo que se hace en cada momento. Para ilustrar esta opinión consideremos lo que nos dicen los manuales acerca de que cuánto más preciso sea el modelo más exactos son los datos. Bueno, eso puede llegar a ser bastante relativo, por mucho que se lo adorne con adjetivos de exactitud. Cabría preguntarse, ¿y cuan precisa es la estimación de coste de la tarea?, ¿y si en tramos de entro de ella para detallar más? Estamos cómo siempre, ¿dónde empezamos (en pasado) a ser precisos?, ¿cuan preciso se puede llegar a ser? Es cómo esas recetas dietéticas de revista dominical en las que, tras enumerar la lista de ingredientes (un vaso de aceite (qué vasos tiene en casa amigo), dos cucharadas de azúcar (cómo va de pulso), dos o tres unidades de esto o lo de mas allá…), nos indica que su contenido calórico es de 95,6 calorías. Pasmao. “Oiga, que se ha dejado los céntimos en su desviación en coste”. ¡Y el presupuesto del proyecto es de diez millones de euros! Algún día hablaremos de órdenes de magnitud…
En la práctica es muy difícil partir con datos precisos, y no quiero decir que no haya organizaciones capaces de conseguirlo. Lo que sí creo que es una moraleja importante es que, aunque se crea que no se dispone de una precisión exquisita, aún se puede beneficiar uno del uso del AVG; lo que no hay que hacer es ser exquisito donde ya no hace falta, y además va a ser incluso contraproducente. Espero no haber sido muy pesado con estas reflexiones, pero es que las considero clave para comprender el uso de cualquier herramienta analítica. A lo largo de mi vida profesional (y no profesional) me he encontrado tanto con detractores y con suicidas defensores de las mismas que, en última instancia, pretenden justificar cualquier resultado con las mismas. Sin embargo, el terreno que se pisa en estos contextos es bastante movedizo. Cualquier modelo analítico contiene una secuencia lógica de pasos que, una vez asumidos, ya no discutimos; pero el problema no radica ahí, sino con qué fidelidad refleja ese modelo la parcela de realidad que pretendemos explicar con él: ahí es donde hay que ser especialmente cuidadosos y críticos. En el caso del AVG, la secuencia lógica es todo lo que hemos explicado hasta el anterior anuncio; la zona pantanosa se nos presenta con la aproximación del modelo, ahí está el factor limitante. Dicho todo esto, entremos ya de lleno con los modelos más populares, que ya están bautizados.
El modelo más sencillo sea, quizás, el de reparto uniforme, ampliamente conocido en el mundo anglosajón como “nivel de esfuerzo” (LOE de su acrónimo en inglés, el siguiente anuncio lo dedicaré a la bibliografía), y está siendo actualmente popularizado por el PMI. Para una tarea cuyo coste tenga una relación directa con mano de obra, este simple modelo puede reflejar bastante bien la realidad. Sin embargo, si no existe esta relación directa, bien porque la dedicación no es uniforme, o porque se le imputan otro tipo de recursos aparte de la mano de obra directa, la aproximación ya no es tan buena. Precisamente, el PMI recomienda su uso en aquellas tareas que no tienen un resultado tangible y que están caracterizadas por un trabajo realizado a una tasa uniforme a lo largo del periodo de realización de la tarea. Existe otro modelo estrechamente relacionado con éste que, por su denominación, puede crear confusión. Me refiero al “apportioned effort”, que literalmente se puede traducir por esfuerzo repartido o prorrateado, término este último que han escogido los compañeros que han traducido el PMBOK al español. El término prorrateado nos puede inducir a pensar que es el mismo que el anterior, aunque realmente se refiere a tareas cuyo trabajo está ligado a otras, como auditorías y controles de calidad, revisión de material de aprovisionamiento, etc., y en las que su grado de avance está ligado al grado de avance de la tarea a la que da soporte. Estos modelos, consistentes en distribuir de forma más o menos continua el coste de una tarea a lo largo de su duración, se pueden complicar (y de hecho así lo hacen algunos paquetes recientes de software) para intentar reflejar con mayor precisión la realidad: ¿por qué ese reparto tiene que ser uniforme y no en forma de campana de Gauss para reflejar que el mayor esfuerzo se concentra en la zona central? ¿Por qué no varios picos porque el trabajo se hace así? La matemáticas metidas sin ton ni son en un paquete de software por gente que nunca ha dirigido un proyecto, y tan sólo se ha limitado a leerse una manual de métodos cuantitativos y aplicarlo al pie de la letra, conducen a estas cosas absurdas. Una cucharada de aceite tiene 5,17392 calorías, oiga.
Los dos modelos anteriores tienen en común el hecho de distribuir uniformemente el coste. El resto de métodos que vamos a abordar lo hacen de forma discreta. Es el caso del ejemplo anterior en el que acreditábamos el coste al final de la tarea, pero se puede acreditar un porcentaje al inicio de la tarea y el restante al final. Ejemplos son 0/100 (acreditar todo el coste al finalizar la tarea), 50/50 (mitad y mitad), 25/75 (el 25% al inicio y el 75% a la finalización), y cualquier otra combinación. El PMI llama a este modelo “fórmula fija”. El modelo se puede generalizar con la inclusión de varios hitos a lo largo de la tarea en los que acreditar coste. Por ejemplo dos hitos más, aparte del inicio y fina de la tarea, y acreditar un 15%, 35%, 35% y 15% del coste respectivamente. El PMI lo llama “hitos promediados”. Estos modelos son más apropiados para tareas que tiene un resultado tangible (o resultados intermedios tangibles) a los que se puede asociar la acreditación de coste. El último modelo de estas características es el de medir el porcentaje completado de la tarea, en este caso el valor ganado es el resultado de multiplicar dicho porcentaje por el coste total planificado de la tarea en cuestión. Este puede que sea el más sencillo de todos, incluso más que el LOE, aunque arrastrará la subjetividad con que se ha medido el grado de avance de la tarea.
Al final, de lo que se trata es de escoger aquél que se considere más adecuado para cada contexto, y que seamos también capaces de utilizar. Ante la duda o la falta de medios para la recolección de datos, lo mejor es utilizar modelos simples como el LOE o porcentaje completado. Cuanto mayor sea el presupuesto del proyecto, en mayor medida se diluirá su inexatitud. Después de todo, las posibles inexatitudes se darán en aquellas tareas que están en curso, porque en aquellas que ya hayan finalizado ya se habrá acreditado todo el valor ganado. Y tampoco habrá muchas tareas en curso en un momento dado. Qué puedo tener, ¿un error de mil euros en una desviación de 60.000 € cuando ya se llevan ejecutados tres millones y medio de euros sobre un presupuesto total de seis millones? Apretemos más, ¿un error de 10.000 €? ¿Realmente merece la pena ser más preciso? Y ojo, que ese error se debería al hecho de haber considerado una distribución uniforme en vez de una con cuatro picos acampanados, o con haber contado unos centimillos más por aquí, por poner un par de ejemplos. Estas son situaciones que he podido constatar personalmente. En proyectos de estas magnitudes se puede ser bastante generoso en el uso del AVG y, lo que es importante, se puede obtener muy buena información al orden de magnitud correspondiente, que un euro no le quite el sueño, amigo.
Finalmente, por lo que respecta a proyectos de pequeña entidad sí que hay que cuidar un poco más las mangas. Aunque también hay que estudiar si merece la pena realmente aplicar el AVG. En este sentido estoy trabajando actualmente con un compañero de profesión en la aplicación de versiones simplificadas del AVG a este tipo de proyectos y, sobretodo, a situaciones en las que se dispone de poca metodología a la hora de recabar datos. Son métodos que a los ortodoxos podrían escandalizar, aunque a los que vivimos en las trincheras hay cosas que hace tiempo que dejaron de escandalizarnos.
De los cuatro grupos de magnitudes que hemos definido a lo largo de esta serie, ver los anuncios número 5 y 6, el primero es el realmente fundamental y crítico. Creo que nos hemos repetido bastante en ello, se ha hecho algún comentario al respecto, pero el lector habrá notado que no nos hemos mojado del todo y no se ha ido al fondo del asunto. Después de todo, el análisis que hemos visto se quedaría 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 éste es precisamente el aspecto más peliagudo del Análisis del Valor Ganado (AVG), no por complejo sino, más bien, por ser un problema de actitud, tesón e incluso ética, tres aspectos que entran dentro del ámbito humano. En este anuncio voy a intentar descender en ese pozo del que, por otro lado, tengo mis dudas que tenga fondo.
Recordemos que el primer grupo está compuesto del coste planificado CP, valor ganado VG y coste realizado CR. Como dijimos en el segundo anuncio, CP 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:
Así, el coste planificado CP en un momento dado del proyecto es la suma de las siguientes contribuciones:
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 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 aún 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 según el modelo de distribución que se haya aplicado.
Tan sólo 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 VG, que va a consistir en ir acreditando cómo se va alcanzando el valor planificado. 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 CP y VGestán estrechamente relacionados en cuanto que el modelo elegido para distribuir el CP 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. Espero que la figura siguiente clarifique esto que estamos diciendo.
Comparar esta figura con la anterior, 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 contrario, que porcentaje llevamos. Sin embargo, hay otras cuyo relleno en rojo no coincide con el relleno negro planificado. En estos casos VG diferirá de CP 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. En el siguiente anuncio abordaremos las diferentes técnicas para realizar esta medición.
Las vacaciones están a la vuelta de la esquina y hemos caído en la cuenta de que no vendría mal una mano de pintura a la casita en la playa, para poder disfrutar mejor de esas vacaciones. Para ello hemos contactado con la pintoresca sociedad ANGELITOS NEGROS C.B., que nos ha pasado el siguiente plan de trabajo: con una dedicación de tres horas diarias a lo largo de diez días nos han pintado la casita, y cobrarán tres euros diarios según una tarifa de un euro la hora –ya había dicho que eran algo pintorescos.
El objetivo de este curioso, aunque simple, proyecto (hasta puede que sea pretencioso llamarle proyecto) es el de ilustrar las características de las diferentes magnitudes que hemos ido viendo a lo largo de esta serie sobre el Análisis del Valor Ganado (AVG). Obviamente, este un ejemplo de proyecto en el que, dada su pequeña entidad, sería ridículo aplicar una técnica como la del AVG. Pero, como decía, el verdadero objetivo del mismo es tan sólo ilustrativo, y no hay como un ejemplo simple para entrever en todo su esplendor las bondades y carencias de un método.
Continuemos pues. Si representamos gráficamente los flujos de caja de cada día y su acumulación a lo largo del proyecto, obtenemos lo siguiente:
Lo primero que llama la atención es la forma de la curva S, parece como si se hubiera tirado de sus extremos hasta convertirla en una línea. Vemos que cuando la distribución en el tiempo de los flujos caja del proyecto es horizontal y uniforme, el coste acumulado del proyecto es una línea recta ascendente que será más empinada cuanto mayor sea el nivel de flujos de caja; es decir, el coste diario. Estamos pues ante un ejemplo extremo de curva S, aunque nos va a ayudar a comprender el tipo de aproximación que realizamos para hacer predicciones, como vamos a ver en breve.
Con este plan en el bolsillo, vamos a considerar dos escenarios:
Escenario 1: el pintor trabaja dos horas diarias durante 15 días y nos cobra un euro diario.
Escenario 2: el pintor trabaja cinco horas diarias durante 6 días y nos cobra 7 € al día.
Veamos los resultados del primer escenario. En la siguiente figura tenemos las curvas S correspondientes al coste planificado, el valor ganado, y el coste realizado:
Cuando la línea roja, que representa el valor ganado acumulado, alcanza el presupuesto previsto es cuando finaliza el proyecto. En el ejemplo esto ocurre cinco días después de lo previsto. La diferencia entre esta línea y la azul, coste realizado, no da la desviación en coste, que nos va dando un saldo a nuestro favor de un euro diario como muestra el correspondiente gráfico:
Otro aspecto aparentemente curioso es que si hacemos la predicción del nuevo presupuesto del proyecto en cada uno de los días del proyecto, PE=(CR/VG)xPP, nos sale siempre que es de 15 €, precisamente el resultado final. Aquí vemos la verdadera esencia de la aproximación lineal que realizamos para definir el nuevo presupuesto estimado, y dijimos que era algo así como el coste que tendría el proyecto a su finalización si se sigue la tendencia actual, de forma lineal añadiríamos ahora. En cualquier otro tipo de proyecto esto no será así, pero la extrapolación que hacemos nos puede servir de advertencia sobre la inercia lineal que lleva el proyecto y hacia donde se puede ir la cosa si no hacemos nada por remediarlo –en el caso de que no vaya bien. Obviamente, dado que entre una sesión de control y otra siempre estamos realizando acciones (la ausencia de ellas ya es una acción en sí misma), la nueva predicción en el siguiente control será diferente: más optimista si hemos tomado medidas o más pesimista si lo abandonamos a su suerte. Por lo que tampoco hay que preocuparse mucho sobre la exquisitez de la aproximación si la tomamos como lo que simplemente es, un indicador sobre el orden de magnitud que puede tomar el proyecto.
Respecto al último gráfico, observamos también el mal comportamiento de la desviación en plazo, línea verde, en los últimos estadios del proyecto. Ya veremos cómo solucionar esto más adelante. Finalmente, veamos los resultados del segundo escenario. En primer lugar las curvas S:
En este caso el proyecto acaba antes de lo previsto, ver cómo la curva roja alcanza antes el presupuesto del proyecto. De la misma manera que en el primer escenario, la predicción del nuevo presupuesto es siempre la misma en cada día de control, e igual al coste final del proyecto: 42 €. Por lo que respecta a las desviaciones, tenemos lo siguiente:
En este caso, la desviación en plazo (línea verde) ya no tiene el mal comportamiento que posee en el caso que el proyecto finaliza fuera de plazo. El ejemplo completo se puede obtener aquí.
Imagine que es el 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 más. 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? ¿Cómo sé que los 20.000 € no son una canica y los 2.000€ una bola de lanzamiento de martillo? O viceversa. O, por qué no, 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 sí se responde: -dime como mides y te diré cómo te comportas, que casi debería dudar ya a estas alturas. 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é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 €. El 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 cuál es ese patrón, tendremos la desviación relativa, que no es más que cuantos euros 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 dentro entre 0 (totalmente ineficiente) y 1 (eficiente), e incluso ser mayor de 1 si supera su máximo rendimiento. ¿Cómo puede ser eso? El motor de un coche difícilmente superará su máximo rendimiento teórico, pero un proyecto es un claro ejemplo de sistema que sí 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 se vea todos los años, pero es posible. Dado que teníamos dos magnitudes que medían las desviaciones en coste y en plazo, podemos definir sus respectivas que midan la eficiencia en coste y en programación. Si para hallar la desviación hacíamos una sustracción, para la eficiencia haremos una división. La magnitud clave es el valor ganado VG. Si la referencia es el coste realizado CR, tendremos una eficiencia en coste a la que llamaremos EC. Si la referencia es el coste planificado CP, tendremos una eficiencia en programación que llamaremos EP. Así pues, tendremos que EC=VG/CR y EP=VG/CP. 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, VG>CR, la eficiencia en programación será mayor que 1; mientras que si hemos gastado menos de lo realmente aportado CR<VG, 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 qué 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, aunque todavía no la serie de anuncios. En el siguiente libro de trabajo de Excel se puede encontrar una plantilla con todas las magnitudes y cálculos automatizados del Análisis del Valor Ganado (AVG) aplicados a un ejemplo concreto. A continuación muestro unas figuras extraídas del ejemplo de Excel para realizar algunos comentarios que considero interesantes. En la siguiente figura 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.
En color amarillo tenemos la evolución de la eficiencia en plazo. Vemos cómo 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ía 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 VG, que al final del proyecto tiene que coincidir con el presupuesto inicial del proyecto (ver este anuncio). Tanto la desviación en plazo que hemos definido, como la correspondiente eficiencia, serán 0 y 1 respectivamente al final del proyecto porque ya se habrá realizado lo que se tenía 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 aunque de eso hablaremos en un futuro anuncio.
En color morado se muestra la evolución de la eficiencia en coste. Esta si que es fidedigna de principio a fin. Vemos cómo esta eficiencia se va empobreciendo 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 caída libre. En los últimos estadios del proyecto observamos cómo 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. Ya puede observar el lector la jugosa información que puede obtener un jefe de proyecto, y sobretodo 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 siguiente figura muestra la evolución del nuevo presupuesto, estimado en cada punto de control, a lo largo del proyecto.
En azul tenemos una línea horizontal que refleja el presupuesto inicial PP proyecto. Frente a éste se muestra, en color morado, el nuevo presupuesto estimado PE. 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.
Antes de continuar con más análisis, y definir nuevas magnitudes para medir el rendimiento del proyecto, hagamos una 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 éste. Estos grupos son:
Primer grupo: magnitudes que se hallan directamente
Coste planificado CP, se determina durante la planificación del proyecto
Coste realizado CR, se mide en un momento dado del proyecto
Valor ganado VG, 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 DC=VG-CR
Desviación en plazo DP=VG-CP
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 PE=(CR/VG)xPP (PP es el CP al final del proyecto)
Estimación de la desviación de coste al final del proyecto DF=PP–PE
Estimación de lo que nos quedaría por gastar EF=PE–CR
Viendo el Análisis del Valor Ganado (AVG) como un proceso, la figura siguiente ilustra el diagrama de dicho proceso:
Aunque el diagrama no es completo, aún faltan más productos de salida del proceso que iremos viendo en sucesivos anuncios, es suficiente de momento para las conclusiones que se establecen a continuación:
En primer lugar, aunque el diagrama no sea completo en su parte derecha, sí lo es a su izquierda: los tres únicos inputs que necesito 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 sólo son tres, de los que uno de ellos, el coste planificado, se halla de una vez para siempre al principio del proyecto. Así sólo 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 lo importante de todo esto es que tenemos 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 acicalá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 cuan 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 MSProject®. 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 más que herramientas. Y, como muy bien dijo Goethe, “soplar no es tocar la flauta, hay que mover los dedos”.
