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

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

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

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

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

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

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

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

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