29 diciembre 2006

El hombre que nunca estuvo allí

Buscando entre las infinitas y caleidoscópicas maneras de clasificar los seres humanos, quizás encontráramos acaso una basada en tres categorías: aquellos que dotan a su vida de una fugacidad inversamente proporcional a la intensidad con que la consumen, los que viven la vida, y los que simplemente la ven pasar ante sus narices cual imágenes errabundas que se pierden en la oscuridad. Si, además, esta clasificación tuviera alguna realidad, Carlos Granell pertenecería sin duda a esta última categoría.

Alrededor de una larga mesa, Carlos se encuentra celebrando su quincuagésimoprimer fin de año con su mujer, sus tres hijos y la familia de su hermana. En televisión están retransmitiendo las doce campanadas aunque sus pensamientos no parecen encajar en el jolgorio familiar que llena el amplio salón de su casa madrileña de Arturo Soria. El tañido de las campanas anuncia el nuevo año y Carlos siente que le quedan 27 años menos que vivir, precisamente los años transcurridos desde el inicio de su carrera profesional. Recuerda cómo en aquel momento sentía que todo lo bueno de la vida le aguardaba; que un mar de posibilidades intactas estaban ahí esperándole para ser materializadas; y que, de alguna manera, estaba llamado para alcanzar el éxito profesional. Lo que no apercibió es que el tiempo también comenzaba a escaparse como lo hacían los granos de arena de su pequeña mano cuando jugaba de niño en la playa. Y que durante los siguientes 27 años no lograría alcanzarlo en su inexorable huída.

Pocos años después se casó con Judith, su primer y único amor, después de más de diez años de noviazgo. Su primer hijo no se demoró mucho. Los otros dos vinieron casi como resultados de sendos intentos por superar el hastío de su matrimonio, postergando su fin con la esperanza de que vendrían buenos tiempos. Luego le acompañaría la fría sensación de no haber llegado a experimentar lo que es la pasión, vivir las emociones al límite. Y aún hoy le acompaña en ese salón lleno de emociones y vacío a la vez. Mientrastanto su carrera profesional avanzaba, aunque solo fuera por la inercia intrínseca que imprime el paso del tiempo. Aunque cada vez ocupaba puestos de más responsabilidad, los días transcurrían para Carlos sin más trascendencia que la de la mera y vacía repetición indefinida de cosas idénticas, jornada tras jornada, semana tras semana, año tras año. En algún oscuro lugar de ese vacío yacía la sensación de que estaba desperdiciando los mejores años de su vida. A pesar de ello seguía a la espera, sostenido por la ilusión de que lo mejor estaba aún por llegar, como si la vida fuera a ser condescendiente con él.

Los cuartos han terminado dando paso a las doce campanadas, y todos los que se reúnen alrededor de la gran mesa del salón sostienen en su mano la copa con las uvas dispuestas para ser engullidas al ritmo que marca el tiempo en su huída. Para Carlos el acto es meramente mecánico, sus pensamientos fluyen al margen de ese ritmo, sigue sin poder conseguir unirse a esa huída en una gran metáfora de su vida. En realidad, sus pensamientos intentan abarcar otro tiempo, ya perdido y, por tanto, inexistente. Un tiempo dedicado a la espera de algo que probablemente nunca llegaría a suceder, a reflexionar sobre la posibilidad de culminar su progreso profesional presidiendo el consejo de una gran compañía multinacional o, al menos, ocupando un cargo de la alta dirección. El progreso era lento, pero siempre quedaba tiempo por delante. Mientras, el propio tiempo persistía en su huída sin que Carlos pudiera aprehenderlo. Y con él se fugaban su juventud, las posibilidades intactas, su matrimonio… Hasta que llegaron los rumores de fusión con una multinacional norteamericana líder en el sector. De eso hace tan sólo año y medio. Carlos ocupaba ya un cargo de gran responsabilidad y se veía a un paso de ocupar otro dentro de la alta dirección de la compañía. Si eso se producía dentro de una gran multinacional, sería el premio a su larga y vacua espera. Pensaba que no estaba mal posicionado para aspirar a llevar el negocio de la multinacional en Europa, dado su actual conocimiento del entorno gracias a las diferentes filiales con que contaba su actual compañía en el continente. La espera de Carlos se aplazó durante 14 meses hasta que, justo hace unos cuatro, la fusión se hizo efectiva. Tan sólo hace 15 días se comunicó la reestructuración organizativa. La estructura directiva intermedia, a la que él pertenecía, había sufrido un duro varapalo; y Carlos formaba parte del 80% de los directivos que iban a ser despedidos. Las campanadas estaban llegando a su fin mientras que un sombrío sentimiento de rabia concomía el alma de Carlos. Cómo le podían hacer esto a él. Cuando por fin le llegaba la oportunidad de ocupar un cargo de alta dirección en una multinacional, no sólo no contaban con él, sino que, además iba a perder su actual puesto. Cómo le podían hacer esto. A él, que había renunciado a las mejores cosas de la vida por esperar una oportunidad como ésa.

El último campanazo tiene lugar entre el griterío de la gente, que en las imágenes de la televisión celebra la entrada del nuevo año. Todo parece comenzar en este mismo momento, el tiempo parece inagotable; pero, entre los últimos estertores del último campanazo, Carlos siente cómo se escapan sus últimas ilusiones, que habían alimentado durante años una vana espera, en una huída que en realidad comenzó hace 27 años.

16 diciembre 2006

Corrección de erratas

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

28 noviembre 2006

Más sobre Software de la Cadena Crítica

En la entrada del pasado 7 de noviembre enumeraba algunos de los paquetes de software de gestión de proyectos mediante Cadena Crítica que consideraba, en mi opinión, como los más relevantes entre los que conozco y personalmente. Esta cadena de sesgos podría ocasionar alguna omisión importante. Pero no es este tipo de omisión al que me quiero referir.

A pesar de que el método de la Cadena Crítica es de un sentido común aplastante, según sus defensores, e infantil, según sus detractores, que haberlos hailos y que, por cierto, no deja de ser otro piropo dados los tiempos de oscurantismo gurú que corren en el mundo del management (el homo economicus se resiste a asimilar que las grandes soluciones son breves, obvias y sencillas), a pesar de ello, decía, este sentido común suele brillar por su ausencia a la hora de implementar el método -en realidad más cosas, pero lo dejamos aquí. Es por ello que no viene mal una ayuda a la hora de implementar Cadena Crítica. He conocido que existen otros consultores expertos en su implementación en nuestro país, utilizando, además, uno de los paquetes que citaba en la citada entrada, ProChain. Estos consultores son Teoce. Dado que el propósito de la entrada era dar a conocer productos y soluciones relacionados con Cadena Crítica, según una petición hecha en otro anuncio anterior, he creído conveniente completar dicha información.

26 noviembre 2006

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

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

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

22 noviembre 2006

Dos desafíos (y 2)

Si pudiéramos por un momento hacer una lista con las soluciones que cada persona que haya leído el anuncio anterior ha escogido para cada uno de los dos desafíos, me siento con bastante confianza para aventurar la posible distribución de resultados. Ahí va: en el primer desafío la mayor parte de la gente habrá optado por el primer remedio –reutilizar el código-, mientras que en el segundo desafío la mayor parte de la gente habrá optado por la segunda alternativa –poner en marcha el plan de contingencia. No tengo forma de saberlo, pero apostaría fuertemente por ello. ¿Por qué? Antes fijémonos en un detalle muy peculiar que tienen en común las situaciones a las que se enfrentan Telesforo y Juanma. En términos monetarios, ambas situaciones son exactamente iguales, en la primera alternativa se pierden 25.000 € y en la segunda existe una probabilidad de 2/3 de perder 40.000 €. ¿Cómo entonces me atrevo a apostar por que sea bastante probable que Telesforo escoja la primera alternativa y Juanma la segunda? ¿Por qué?

Eso es al menos lo que sugieren unos estudios realizados por nuestros viejos conocidos Kahneman y Tversky en los que analizan las respuestas que damos las personas a situaciones análogas. En este caso lo que se pone en el punto de mira es nuestra tendencia de asumir riesgos para evitar pérdidas y evitarlos para obtener ganancias. Uno más de nuestros sesgos cognitivos. ¿Qué no te lo acabas de creer? Si realizas presupuestos, juegas a la bolsa, eres analista de riesgos o te vas a montar una empresa, haz un ejercicio de introspección. Y ojo, que estamos hablando de una mayoría de la gente en/o una mayoría de las situaciones. Pero ahí está. Tal y como estaba planteado el caso de Telesforo, la primera alternativa era la de recuperar –ganar- 15.000 € de forma segura frente a una probabilidad de 1/3 de recuperar 40.000 €. Pues eso, que más vale pájaro en mano que ciento volando. En cambio, en el caso de Juanma la primera alternativa era perder de forma segura 25.000 € frente a una probabilidad de 2/3 de no perder nada.

08 noviembre 2006

Dos desafíos (1)

Telesforo se pasa el dedo índice de su mano izquierda por el estrecho margen que queda entre la nuez de su garganta y el cuello de su impecable camisa blanca de corte italiano. En ese instante, la corbata de Ermenegildo Zegna se le asemeja más a una soga que lo va a estrangular de un momento a otro. La cosa no es para menos. A causa de una ligereza cometida durante la toma de requerimientos, unos meses antes, uno de los módulos de software del CRM que está implantando en un banco no ha pasado las pruebas unitarias. Y no es que no las haya pasado, con toda probabilidad va a haber que rehacerlo por completo. Unos 40.000 € tirados a la basura. Bueno, quizás el asunto no esté completamente negro. A veces el insomnio, como el de la noche anterior, sirve para pergeñar algún parche que otro.

Después de meditarlo a la luz de la vigilia, se le ocurrieron dos remiendos alternativos a rehacer por completo el módulo y perder 40.000 €. El primero es consecuencia inmediata de descubrir que, en realidad se podría reutilizar una parte del código recuperando así unos 15.000 €. El segundo consiste en realizar unas pequeñas modificaciones en las programaciones de los módulos restantes, con un coste despreciable, para que, una vez integrados todos los módulos, la aplicación funcione en su conjunto –hay que ver lo que da de sí una noche de insomnio. El punto de emoción lo da el hecho de que la probabilidad de que salga bien es de 1/3 y, por tanto, 2/3 de que no salga bien y acabe rehaciendo el módulo por completo –Telesforo se empleó a fondo en su gran noche. Y ahora viene el desafío nº 1: ¿cuál de las dos soluciones escogeríais vosotros, estimados lectores?

Otros 40.000 € va a palmar Juanma, un analista de una pequeña firma de capital riesgo que acaba de abrir la ventana de su oficina para que la fresca brisa de la mañana le aclare un poco las ideas. Por un instante de tiempo infinitesimal, su mirada se cruza con la de otro tipo en el edificio de enfrente que se pasa angustiado el dedo entre su cuello y el de su camisa. Podría perder esos 40.000 € que se ha gastado en el estudio de un proyecto empresarial de unos emprendedores que, tras demostrarse que la inversión sería suicida, no podrá recuperar –lo que se conoce como costes evitables. Los podría perder a menos que considere alguna de las dos alternativas siguientes. La primera consiste en invertir en otro proyecto más viable de esos emprendedores a cambio de pagar sólo 25.000 € por el estudio realizado (el resto correría a cargo de los emprendedores). Y la segunda poner en marcha cierto plan de contingencia que le ofrece una probabilidad de 1/3 de que no pierda los 40.000 €. Y con esto, el desafío nº 2: ¿cuál de las dos soluciones escogeríais vosotros, estimados lectores?

Que lo disfrutéis.

07 noviembre 2006

Software de Cadena Crítica

En un comentario a un anuncio anterior titulado “Ojo con el método del camino crítico”, Juan Ignacio pone, en mi opinión, el dedo en la llaga entre la diferencia entre un concepto y una respectiva herramienta asociada al mismo, y su aplicación a problemas reales mediante la respectiva ayuda de una herramienta. Finalmente, se pregunta sobre la existencia de herramientas de software para el cálculo de la cadena crítica de un proyecto. Dada la antigüedad del anuncio, he creído conveniente escribir un nuevo anuncio en vez de una nota en el anuncio anterior.

Efectivamente, existen diversos paquetes de software que calculan, no sólo la cadena crítica de un proyecto, sino los amortiguadores y demás conceptos del método de la cadena crítica de Goldratt. Entre ellos destacan:

  • Concerto, es uno de los pioneros, basado en la solución original de TOC para operaciones. No es una aplicación al uso sino que suele formar parte de un proyecto de consultoría. En España se puede contactar con CMG Consultores.
  • PS8.
  • Cc-Pulse y cc-MPulse, que funcionan como complementos a MS Project.
  • ProChain, también un complemento a MS Project.

Otra cosa es que el homo economicus sea capaz de hacerlos funcionar, tanto conceptos como herramientas de software. De estos problemas habla Goldratt en su Saga para mejorar la Producción, donde se pregunta cómo, si la mayor parte de los profesionales están de acuerdo en la efectividad de una herramienta, sólo una ínfima parte consigue implementarla con éxito –¿es quizás este el fracaso al que se refiere Juan Ignacio? Goldratt llega a la conclusión de que lo que tenían en común esta ínfima parte era su carisma y carácter analítico. Parece ser que en esta era del capital humano lo que se escribe acerca del liderazgo es inversamente proporcional a lo que se ve como peatón de la vida.

31 octubre 2006

Sobre recompensas y castigos (y 2)

Desde que hace unos 150.000 años nuestros antepasados más cercanos comenzaron a deambular por la sabana africana hasta que fundamos la primera ciudad, hace apenas unos ocho mil, la dimensión y complejidad de los problemas a que nos sometía aquel entorno no era, ni mucho menos, la de los nuevos problemas a que nos somete este muy reciente e intrincado entorno al que llamamos civilización. Y entre esos problemas destacan los que tienen que ver con el cálculo de probabilidades y el uso de la estadística. Digamos que nuestro cerebro no lleva de serie un módulo para la resolución intuitiva, y más o menos automática, de dicho tipo de problemas. Y no lo tenemos simplemente porque no era necesario en aquel bucólico, aunque peligroso, hábitat y por tanto la evolución, que es el mecanismo por el que vamos incorporando estos módulos, muy economizador en este aspecto por cierto, no lo incorporó. Quizás ahora va siendo el momento, pero qué son ocho mil frente a ciento cincuenta mil. En cambio, sí disponemos de un limitado número de principios heurísticos que reducen a simples operaciones de juicio las complejas tareas de evaluar probabilidades y hacer predicciones cuantitativas, que sí nos fueron de mucha utilidad en aquel peligroso hábitat. Porque estos atajos cognitivos, aunque en la actualidad nos pueden llevar a errores severos y sistemáticos, sí fueron más fiables durante nuestra etapa sabanera dada la menor complejidad de aquel entorno. En el fondo, era más efectivo enfrentarse a una situación de incertidumbre o peligro potencial, o salir poniendo los pies en polvorosa, sin pensar, que perder el tiempo intentando evaluar la verdadera dimensión del peligro; como dice Steven Pinker, “nuestro cerebro está hecho para el ajuste, no para la verdad”. El entorno debió de seleccionar el primer comportamiento y la evolución lo incorporó a nuestros cimientos.

Todo esto viene a colación porque lo que le ha ocurrido a Santiago es que ha caído en uno de estos engaños o sesgos que nos producen las heurísticas o atajos cognitivos. Concretamente, el efecto que ha observado Santiago bien puede haber sido el de regresión a la media, observado por primera vez por Francis Galton. Es muy común entre el homo economicus buscar relaciones de causa-efecto allí donde muchas veces sólo interviene el azar. Para el caso de Santiago, la regresión a la media consiste en lo siguiente: si escogemos los resultados de dos evaluaciones desempeño con medias de, digamos, 7 sobre 10 las dos, y seleccionamos una muestra de individuos con las mejores puntuaciones en la primera evaluación siendo su promedio de, digamos, 9 (una desviación de dos puntos respecto de la media), entonces el promedio de los mismos individuos en la segunda evaluación será, con bastante probabilidad, menor que 9. Es decir, se acercará a la media. Lo mismo ocurre con promedios por debajo de la media. No es extraño pues que quien saque una puntuación extrema en una evaluación no la repita en la siguiente, ¡lo que no quiere decir que siga siendo alta o baja! Los resultados extremos se deben más al puro azar, ¿suerte?, que a las propias habilidades.

Nuestra mala interpretación del fenómeno de la regresión a la media es uno de los muchos sesgos y heurísticas que estudiaron Amos Tversky y Daniel Kahneman, y que se pueden encontrar de forma resumida en un artículo que publicaron en Science en 1974. En concreto se enmarca dentro de la heurística de la representatividad, por la que las personas evaluamos la probabilidad de que un proceso desencadene cierto evento en base al grado en que el evento se parece al proceso. Imaginemos que nos han descrito a cierto jefe de proyecto de sistemas de información del sector bancario como una persona tímida e introvertida, servicial aunque con poco interés en la gente y en el mundo de la realidad, amante de las estructuras y el orden, y con gran pasión por el detalle. A continuación nos piden que evaluemos las probabilidades de que su titulación sea la de, digamos, empresariales, economía, informática, psicología, derecho, etc. La heurística de la representatividad hace que a la hora de determinar la probabilidad de que, por ejemplo, el jefe de proyecto sea un informático lo hacemos en base al grado en que dicho individuo, por la descripción que nos han hecho de él, sea representativo del estereotipo de informático.

Para finalizar, vamos a retomar el caso de Santiago para establecer algunas conclusiones acerca de la efectividad de los castigos y las recompensas. Como hemos visto, la no comprensión del efecto de regresión a la media puede conducir a una sobreestimación de la efectividad del castigo y a una subestimación de la efectividad de la recompensa. Todo por nuestra predisposición innata a ser engañados por el azar. En nuestra sociedad, producto de estos últimos ocho mil años de civilización, solemos administrar un sistema de recompensas para el buen rendimiento y de castigos para el mal rendimiento. Ahora bien, sólo por un mero efecto del azar, y no del propio sistema de recompensas y castigos, el rendimiento tiene gran probabilidad de mejorar después de un castigo y de empeorar después de una recompensa. Por tanto, como concluyen Tversky y Kahneman, la condición humana es de tal manera que, solamente por simple azar, las personas somos recompensadas con frecuencia por castigar a otros y también castigadas con frecuencia por recompensar a otros. ¿Nos suena esto? ¿Qué cosas, eh? La sabana persiste en el inconsciente colectivo.

24 octubre 2006

El verdadero valor de la metodología

Un conjunto de frases escritas en un papel en forma de reglas, normas y procedimientos acerca de lo que hay que hacer en un proyecto no es una metodología. A aquellos a quienes les encanta aconsejar sobre lo que hay que hacer en un proyecto, y/o viven de ello, como puede ser mi caso, posiblemente esta afirmación les haya puesto alerta y les haya incitado a desconfiar sobre el tema de este anuncio, y/o de mi buen juicio. Pero una cosa es decir cómo hay que hacer algo, y otra muy distinta hacerlo. De todas las dudas que pueda estar generando este comienzo, tan sólo quiero disipar una: no voy a arremeter contra la metodología, ni mucho menos, sino todo lo contrario. Así pues, vamos a quitar un poco de hierro a la afirmación con la que comenzaba este anuncio, que más bien estaba aderezada del simbolismo de la pintura de Magritte. En realidad, como dice Harold Kerzner, “lo que convierte a esa hoja de papel en una metodología es la forma en que la organización la acepta, apoya y ejecuta”. Y como todos sabemos, reconozco que es ingenuo pensarlo en voz alta, del dicho al hecho hay un trecho.

Corren tiempos de popularización de la disciplina de la dirección de proyectos, o project management si pretendemos darle cierto tono de distinción al asunto –ante ciertas audiencias it is a must-, y por ende el de metodologías al respecto. Sólo en el campo de las Tecnologías de la Información pegas una patada a una piedra y te salen unas cuantas –cada cuál que escoja aquella que más le quita el sueño, el sueño de la metodología produce monstruos. Y cada vez somos menos fieles a una dada y la cambiamos por el último grito que se ha puesto de moda con la esperanza, en el mejor de los casos, de que resuelva los problemas que no pudimos con la anterior. Es posible que, según qué criterios, las haya mejores o peores; aunque si uno se fija bien podría llegar a descubrir que en el fondo son la misma mona con diferentes vestidos, sean o no de seda. ¿Acaso lo que ocurre es que, en realidad, no son de ninguna utilidad? Esta es invariablemente la conclusión inmediata, y errónea, a la solución de un problema mal planteado. El callejón sin salida al que solemos llegar no es debido a la metodología en sí sino al mal uso que se suele hacer de ella. No basta con escribir lo que hay que hacer sino reflexionar acerca de ello para saber por qué, cuándo, cómo y de qué manera hay que hacerlo. Y, lo que es más importante, en qué medida eso da soporte a la cultura concreta de la organización a la que se va a aplicar en vez de entrar como un elefante en una cacharrería e intentar, y digo intentar porque desde mi humilde experiencia aún no he conocido un caso en el que haya pasado de un mero e infructuoso intento, poner patas arriba buenas prácticas ampliamente asentadas en la organización surgidas desde su seno para resolver problemas reales de un mundo real.

El PMBOK es un ejemplo de extenso cuerpo de conocimiento, colección de buenas prácticas y definición de procesos que conforman una metodología, muy genérico pero bastante extensivo. Sin embargo abundan los casos en que se suele tomar como el Renault de nuestro flamante bicampeón de Fórmula 1 para lanzarse a tumba abierta para descender a 300 km/h el Angrilú, con los resultados obvios y esperados. Y eso que en sus últimas líneas de la sección 1.1, en la página 3 de la edición en español del PMBOK, este advierte, y cito textualmente:

“Buenas prácticas” no quiere decir que los conocimientos descritos deban aplicarse siempre de forma uniforme en todos los proyectos; el equipo de dirección del proyecto es responsable de determinar lo que es apropiado para cada proyecto determinado.

Las comillas y el texto en negrilla pertenecen al texto original. A ver si es que nos da por usar la página 3 del PMBOK para encender la pipa de Magritte…

17 octubre 2006

Sobre recompensas y castigos (1)

Santiago es una persona que se encuentra en su madurez profesional y personal. A lo largo de su trayectoria profesional ha visto de todo y sus vivencias le han llevado a moldear una visión no muy optimista de la condición humana. A ello ha debido contribuir en gran parte su gusto por la disciplina y su dificultad para transmitir el reconocimiento por las cosas bien hechas, aunque en su foro interno es consciente de ello y realmente lo valora. Cree que no hace falta expresarlo con palabras –seguro que las otras personas saben interpretar en mi actitud el reconocimiento, piensa para sí.

Hace tres años, después de más de veinte dirigiendo todo tipo de proyectos, lo nombraron director de una de las unidades de negocio de la compañía. Entre otros, tiene bajo su responsabilidad alrededor de 20 jefes de proyecto. Una de las tareas que se le encomendaron a Santiago, al tomar posesión de su nuevo cargo, fue el diseño de un sistema de evaluación del rendimiento de los jefes de proyecto. Para tal fin asistió a unos seminarios sobre métodos de evaluación personal. Allí le hablaron, entre otras cosas, sobre la importancia del reconocimiento y la retroalimentación positiva, aspectos que no significaban mucho para Santiago hasta ese momento. Al finalizar los seminarios, decide hacer un esfuerzo e incorporar recompensas al sistema de evaluación aunque, como firme creyente en la disciplina, no abandona las sanciones al pobre rendimiento. Lo hace de la siguiente manera: la evaluación se realiza cada semestre, de manera que se recompensan los rendimientos más destacados, los que se encuentran claramente en el extremo superior de la distribución, y se penalizan los rendimientos que se encuentran claramente en el extremo inferior de la distribución.

Después de tres años aplicando el sistema se ha encontrado con los siguientes resultados, no tan sorprendentes para él. Aquellos que habían obtenido un rendimiento destacado en un semestre, y se les había recompensado por ello, habían bajado su rendimiento en el siguiente semestre, acercándose más el rendimiento medio. En cambio, aquellos que habían obtenido un mal rendimiento en un semestre mejoraban en el siguiente ascendiendo hacia el rendimiento medio. Salvo contadísimas excepciones, de esas que, como a él le gusta pensar, confirman la regla, podía afirmar que en término medio así eran las cosas. La conclusión a la que ha llegado es que las recompensas verbales no sólo no son beneficiosas, sino más bien perniciosas, mientras que los castigos verbales si son beneficiosos, como siempre había pensado.

¿Crees que el argumento de Santiago es correcto? ¿Es una pérdida de tiempo eso del reconocimiento? ¿Qué falla en el procedimiento de Santiago?

19 septiembre 2006

Creer o pensar críticamente

Pertenezco a esa generación que tuvo su despertar adolescente en la década de los ochenta. En ese periodo convulso en el que se entrelazan los primeros logros personales y los primeros desengaños, Golpes Bajos cantaba que corrían malos tiempos para la lírica. En realidad, por lo que respecta al pensamiento crítico, nunca han corrido buenos tiempos. Es algo que he ido constatando a lo largo de mi experiencia en diferentes ámbitos profesionales, y sociales en general -mundo académico incluido. La empresa, y el microcosmos de los proyectos en particular, tampoco se libran de esa extraña experiencia. Se habla mucho de aprender cuando lo que se observa es una simple clonación a granel de conocimientos ausente de cualquier atisbo de reflexión acerca de su naturaleza. Se cree en los conocimientos y no se discierne entre ellos y los supuestos que los sustentan. Se llama experiencia al simple hecho pasivo de ver pasar el tiempo más que a vivirlo de forma activa, a aprehenderlo.

El creacionismo se ha convertido en el blanco más fácil de los defensores del pensamiento crítico, pero actitudes similares se encuentran en cualquiel otro ámbito. Como por ejemplo el management, campo en el que últimamente proliferan conceptos, extraídos de otros contextos que no tienen nada que ver, como fórmulas de Einstein, la física cuántica o el conjunto de Madelbrot. Siempre ha sido más fácil ver la paja en el ojo ajeno que la viga en el propio -alguna razón evolutiva habrá para ello, supongo.



Abre pues los ojos, compañero.

Pincha sobre la imagen para ver su procedencia.

08 septiembre 2006

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

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



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

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


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

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


Las claves para el cálculo los encontramos en el área delimitada por el círculo verde. Y ahora es cuando viene la aproximación –a estas alturas ya deberíamos estar acostumbrados a ello :-). Vamos a considerar que la porción de curva CP comprendida entre los valores CP(5) y CP(6) es recta. Hay dos conclusiones que podemos extraer de esto:
  1. Esta asunción se aproximará más a la realidad cuanto más pequeña sea la escala de la dimensión temporal –el eje horizontal; esto es, semanas mejor que meses, mese mejor que trimestres, etc. Pero que no nos ciegue esto; no hay que olvidar que siempre hay un límite en el que el ruido del entorno invalidará cualquier efecto producido por ser más preciso.
  2. Hay que desconfiar de aquellos que emiten juicios categóricos del tipo “la lógica matemática demuestra que…”. La matemática dirá lo que tenga que decir en su contexto. En el que nos manejamos nosotros sería más conveniente un juicio del tipo “los siguientes resultados ofrecen una desviación bastante aproximada por la razón que…”. La experiencia me dice que cuanto más categórico es un argumento, menor es la idea que tiene sobre el asunto el que argumenta.
Pero continuemos con el cálculo. Si ampliamos la zona rodeada por el círculo verde, tenemos la figura siguiente:


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

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

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


Podemos comprobar que este indicador 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.

01 septiembre 2006

Arrieros somos…

… y en el camino nos encontraremos.

En el último anuncio constatamos que casos como el de los dos jefes de proyecto y la UTE –del tipo dilema del prisionero- ponen en jaque nuestra concepción de racionalidad. No hay mejor forma de resumir el conflicto del dilema que recordar lo que una vez dijo Oscar Wilde: “puedo resistirme a cualquier cosa menos a la tentación”. No cabe duda que la tentación alcanza su punto álgido cuando ambos oponentes piensan que sólo se enfrentarán al dilema una vez un sus vidas. Pero, ¿qué ocurre si nos volvemos a encontrar ante un dilema similar, no una ni dos, sino varias veces. Después de todo, el mundo de los negocios, y el de los proyectos en particular, es un escenario de caminos que se entrecruzan a lo largo del tiempo. Si sé que solamente me enfrentaré al otro jefe de proyecto una vez en la vida, aún puedo valerme de su ingenuidad para desertar, esperando que el coopere, para llevarme el máximo beneficio. Pero si nos volvemos a encontrar, ¿cómo actuará esta vez? ¿Entraremos en una escalada de destrucción mutua?

Para averiguarlo, Robert Axelrod pidió a varios especialistas en teoría de juegos, economistas, sociólogos, politólogos y psicólogos que aportaran estrategias para simular por ordenador un dilema iterativo del prisionero; como por ejemplo cooperar siempre, cooperar y desertar alternativamente, cooperar o desertar según el resultado de lanzar una moneda al aire, etc. Todas las estrategias se enfrentaban dos a dos e iban acumulando el número de puntos obtenidos en cada lance. La estrategia ganadora fue una muy sencilla denominada “donde las dan las toman”. Era una estrategia que ocupaba cuatro líneas de código y que venía a decir coopera la primera vez y luego haz lo que haya realizado el oponente en la partida anterior. El lector puede encontrar un simulador en el siguiente sitio, hay que seleccionar un par o más de estrategias (tit_for_tat es la donde las dan las toman) e indicar el número de rondas. Notar que puede haber algunos enfrentamientos en los que no se la ganadora, aunque sí en el cómputo total. En el blog de Mario López de Ávila podemos encontrar un ejemplo muy interesante del valor de esta estrategia en su comentario del libro “la estrategia de los delfines”. Ver el dilema iterativo del prisionero como una pauta de comportamiento podría ofrecer una luz sobre por qué, a pesar de los pesares, la cooperación sigue presente independientemente de significado ético que podamos atribuirle. Imaginemos que ahora sometemos a una selección artificial a las estrategias que no han superado como otras cierto umbral de puntuación en momentos dados, ¿qué estrategia tiene más probabilidades de llegar al final? Obviamente, la naturaleza no cuenta solamente con un mecanismo de selección, sino con mutaciones al azar que en nuestro juego iterativo equivaldría a la aparición de nuevas estrategias no necesariamente cooperativas. Y aquí es donde entramos en el siguiente paso.

Aún así, se puede llegar a una situación de equilibrio como describió el biólogo evolutivo John Maynard Smith en su dilema del los halcones y las palomas. Imaginemos una población en la que solamente convive una especie con sólo dos tipos de comportamiento, que llamaremos halcón y paloma. Si un halcón encuentra comida y está presente otro miembro de la especie, luchará por conseguirlo. En cambio, si es una paloma la que encuentra comida estando presente otro miembro de la especie, nunca iniciará una lucha, huyendo si la atacan y amenazando si no. Consideremos que el valor del alimento es de 50 puntos. Si no se consigue el alimento después de haber atacado se es herido y se pierden 100 puntos. Finalmente, por un acto de amenaza se pierden 10 puntos, independientemente de si se consigue o no el alimento. Con todo esto podemos construir la tabla de resultados. Cuando un halcón se enfrenta a otro halcón, los dos atacan, uno se lleva el alimento y gana 50 puntos, y el otro resulta herido y pierde 100 puntos; el resultado medio para el halcón en este tipo de enfrentamientos es pues de -25 puntos. Cuando un halcón se enfrenta a una paloma, ésta huye quedándose con 0 puntos mientras que el halcón consigue los 50 puntos. Finalmente, cuando una paloma se enfrenta a una paloma, las dos amenazan, una se lleva el alimento y gana 40 puntos, y la otra no y pierde 10 puntos. El resultado medio para la paloma en este tipo de enfrentamientos es pues de 15 puntos -40 menos 10 dividido por 2. La tabla es la siguiente:


Con una población inicial de palomas, todo el mundo consigue por término medio 15 puntos. Nadie resulta herido y todos consiguen alimento. Imaginemos que se produce una mutación y surge un halcón, conseguirá siempre alimento (50 puntos) sin coste alguno. Con una poco población de halcones, su ventaja les hará prosperar teniendo descendientes su comportamiento de halcón. Pero si llegan a ser numerosos habrá mas enfrentamientos entre halcones, perdiendo de media 25 puntos disminuyendo así su población. La paloma se las arreglará otra vez bien, volviendo a aumentar su población y volviendo al punto de partida. Como se ve, los extremos no son estables habiendo una evolución hacia un término medio. Esto es lo que se conoce en teoría de juegos como equilibrio mixto o de Nash, hallazgo que, entre otras cosas le valió el premio Nobel de economía de 1994. En este sitio se puede jugar al juego de los halcones y las palomas, cambiando el sistema de puntuación, y comprobar cual es el punto de equilibrio. Para la tabla que hemos considerado arriba, la misma que la que hay por defecto en la simulación, se obtiene que el punto de equilibrio se alcanza para una población de halcones del 58,3% o, lo que es lo mismo, cuando en la población hay cinco palomas por cada siete halcones -¿será nuestro mundo así?...

¿Es compatible esto con la metáfora de los delfines? Resulta que el resultado es el mismo que si cada miembro de la población actuara como un halcón el 58,3% de las veces, y como una paloma el 41,7% de las veces. ¿Los humanos hacemos eso? Después de todo, amigos lectores, una lectura de Maquiavelo nunca viene mal. En este resultado, que recibe también el nombre de estrategia evolutivamente estable, la puntuación media de la población es de 6,25 puntos frente a los 15 puntos de una idílica población formada sólo por palomas. La situación estable no tiene por qué ser necesariamente el mejor de todos los mundos posibles; así que no se queje de la fauna que convive en su proyecto, hombre.

30 agosto 2006

Cooperar o no cooperar, ése es el dilema

Si analizamos el dilema al que se enfrentaban los dos jefes de proyecto de la UTE a la luz de la herramienta estratégica presentada en el último anuncio, llegamos a una solución racional producto de que ambos escojan la estrategia de no recortar el plazo. Efectivamente, en esta solución situada en la casilla inferior derecha de la tabla -en la que ambos obtienen una desviación en presupuesto nula-, la única forma de que cada jefe de proyecto pueda mejorar su resultado -es decir una de las soluciones de los cuadros superior izquierdo o inferior derecho producto de que uno escoja la estrategia de recortar el plazo y el otro no-, es a costa de que el otro jefe de proyecto empeore su resultado, con lo que si uno fuera a utilizar la estrategia de recortar el plazo el otro también lo haría para no quedar como un primo, lo que nos lleva a la solución superior izquierda en la que ambos tienen una desviación negativa de 10.000 €. Una solución que es, a todas luces, peor que la inferior derecha –y para el proyecto no digamos. Así pues, si nos comportamos como seres racionales, y no como unos locos de atar como dice el siciliano, la única solución buena para ambas partes es la inferior derecha en la que ambos jefes de proyecto no se gastan ni un euro más ni uno menos de sus respectivos presupuestos –si alguien está pensando que tampoco es para echar muchos cohetes que haga una reflexión acerca del estado presupuestario de sus proyectos o eche un vistazo a las estadísticas.

Hasta aquí la teoría. En la práctica mucho me temo que el resultado más probable sea el de la casilla superior izquierda. Y seguro que al lector, durante sus reflexiones sobre este dilema, se le habrán pasado por la cabeza multitud de situaciones de la vida similares, muchas más de las que a todos nos gustaría admitir, con resultados igualmente análogos. Hay que notar, además, que esta trágica solución no sólo no es la mejor para ambos jefes de proyecto, sino que supone un gratuito descalabro económico para el proyecto en su totalidad y para la UTE o la organización en general –hecho que muy bien destaca un comentario anónimo al anterior anuncio. Aún así, la naturaleza humana parece llevar en muchos casos a este tipo de situaciones aparentemente irracionales. Estudiando este tipo de comportamientos humanos andaban dos investigadores de RAND cuando, a principios de 1950, idearon un dilema con las mismas características del que se enfrentan nuestros jefes de proyecto, y que fue popularizado posteriormente con el nombre de dilema del prisionero. Utilizando su terminología, la solución de la casilla superior izquierda, en la que ambos jefes de proyecto recortan el plazo, recibe el nombre de deserción, mientras que la de la casilla inferior derecha, en la que ambos no recortan el plazo, recibe el nombre de cooperación. En la cooperación ambos jefes de proyecto renuncian a la tentación de elegir sus mejores estrategias para obtener el mayor beneficio que se puede obtener de forma colectiva, ya que si ambos escogen sus mejores estrategias les irá indudablemente peor. La lógica está clara; pero, ¿puedo confiar realmente en la otra parte? La tentación a desertar es fuerte: si uno renuncia a su mejor estrategia, y el otro no, pierde 20.000 € de su presupuesto mientras que el otro gana 10.000 €. ¡A pesar de que el proyecto en su totalidad seguiría perdiendo 10.000 €! Pero a estas alturas en la escalada de desconfianza, ¿quién piensa ya en el proyecto? Esta es la esencia de lo que los investigadores de RAND quisieron transmitir con el dilema del prisionero.

En el comentario que hace elnidodelescorpion, adelanta otros aspectos relacionados con el dilema del prisionero, tales como el de la comunicación entre ambos jugadores para llegar a un acuerdo de mutuo beneficio, y el de qué ocurre si nos volvemos a encontrar para jugar dicho juego. Sobre la cuestión de la iteración hablaremos en el siguiente anuncio, pues tiene consecuencias importantes para una posible solución del dilema. Por lo que respecta a un cuerdo entre las partes, una negociación previa a la toma de la decisión siempre allanará el camino para la confianza mutua, hecho que puede mitigar la tentación de desertar. Aunque no en todas las situaciones de la vida la deserción es una mala opción. El dilema del prisionero se encuentra también detrás de actividades como una guerra de precios. Las regulaciones que hacen los gobiernos para asegurar la libre competencia y la defensa de los consumidores no hacen más que fomentar la deserción entre las empresas de un mismo sector para evitar que lleguen a acuerdos para pactar precios altos que les haga obtener grandes beneficios en detrimento del consumidor. Esta última situación sería la de cooperación.

En cualquier caso, la comunicación tampoco asegura que el acuerdo se vaya a mantener a la hora de la verdad. Para muestra, un botón. Cosas de la naturaleza humana.

22 agosto 2006

Cine y dilemas

En un viejo anuncio caíamos en la cuenta de que la bondad de una decisión no se puede evaluar desde el punto de vista de los resultados sino en base a la información disponible en el momento en que se tomó la decisión. Allí considerábamos un ejemplo de una buena decisión con un mal resultado. En el film “Indiana Jones y la última cruzada” asistimos a la escenificación de todo lo contrario. Hacia el final de la película nos encontramos en el cañón de la luna creciente, lugar en el que se encuentra escondido el Santo Grial. El padre de Indy se encuentra herido de muerte y el único remedio es darle de beber del Santo Grial. Pero hay un problema; junto con el verdadero cáliz se encuentran otros más, de manera que no es obvio determinar cuál es el verdadero. Para darle un punto más de emoción al asunto resulta que beber de un cáliz falso no es un acto para nada saludable, pues provoca la muerte del intrépido bebedor. Ahí es ná. Indy, después de elegir un cáliz al azar, y en todo un ejercicio de heroísmo digno de su personaje, decide probarlo antes de ofrecérselo a su padre. El cáliz resulta ser el verdadero Santo Grial y así consigue salvar la vida de su padre. Gran resultado, pésima decisión. Para entender el por qué, visitemos antes el escenario de otra película.

En la “La princesa prometida”, el pirata Roberts reta al siciliano a una batalla de ingenio consistente en un juego mortal. Roberts sirve un vaso de vino al siciliano y se sirve otro para él mismo; uno de ellos contiene un terrible veneno que causa la muerte de forma inmediata. El juego comienza cuando Roberts pregunta al siciliano en qué vaso se encuentra el veneno, y finaliza cuando este último ha decidido y ambos han bebido, determinándose quien de ellos está vivo y quien muerto. La reflexión que hace el siciliano constituye un ejemplo perfecto de la reflexión estratégica que promueve la teoría de juegos. Dice el siciliano: “todo lo que tengo que hacer es averiguarlo a partir de lo que conozco sobre ti. ¿Serías el tipo de hombre que pondría el veneno en su propio vaso o en el de su enemigo? Un hombre inteligente pondría el veneno en el vaso propio, ya que sabe que sólo un loco de atar aceptaría el vaso que le han ofrecido. Yo no soy un loco de atar, así que claramente no puedo escoger tu copa. Pero tú debes saber que yo no soy un loco de atar, lo habrás tenido en cuenta así que claramente no puedo escoger mi copa”. La batalla de ingenios sigue con reflexiones de este tipo hasta que al final el siciliano elige un vaso, ambos beben y el siciliano muere; el veneno estaba en ambos vasos y el pirata Roberts era inmune al mismo. Detrás de la cortina de humor que envuelve la situación, hay dos ilustraciones importantes que se pueden extraer. La primera consiste en el uso del pensamiento estratégico: “qué haría teniendo en cuenta lo que haría la otra parte teniendo en cuenta lo que yo haría teniendo en cuenta lo que haría la otra parte teniendo en cuenta…” En fin, cualquiera que haya echado algunas partiditas al ajedrez sabrá de qué va el asunto. Una forma de representar en un diagrama esta reflexión es la siguiente:


En la tabla se confrontan todas las estrategias posibles de cada uno de los dos jugadores y en cada cruce se ponen los resultados de cada movimiento -el color del resultado de cada jugador coincide con su respectivo color en la tabla. Dos jugadores racionales, como dice el siciliano, que conocen las reglas de juego, hallarán de forma simultánea la combinación de estrategias que llevan a un resultado óptimo para ambas partes –notar que si yo sigo la estrategia que da el mejor resultado para mí pero no coincide con la estrategia que lleva al mejor resultado para la otra parte, no puedo esperar que ésta siga su respectiva estrategia… a menos que sea un loco de atar. En la batalla de ingenio no hay una solución dominante para ambas partes, por lo que lo único que en realidad puede hacer el siciliano es jugársela a cara o cruz.

La segunda ilustración consiste en determinar si se está jugando o no al mismo juego, en la línea de lo que se comenta en un anuncio del blog del nido del escorpión. Al haber puesto un veneno en ambas copas, del que es inmune, el pirata Roberts ha cambiado las reglas del juego. El siciliano se la juega con una moneda con los dos lados iguales ¡y en ningún caso los de su elección! La tabla correspondiente es la siguiente:


Ahora ya tenemos la herramienta de análisis para ver por qué Indiana Jones había tomado una mala decisión, pese al resultado exitoso. En la tabla de estrategias confrontaremos la decisión de probar o no probar frente a la posibilidad de que el cáliz sea el verdadero o no. El resultado será el número de vidas ganadas o perdidas (estas últimas representadas por números negativos). La tabla es la siguiente:


En este caso sí hay una estrategia clara para Indy, que es precisamente la de no probar el cáliz antes de darle de beber a su padre. Efectivamente, mediante la decisión de no probar se salvaría una vida en caso de ser el verdadero Grial mientras que sólo se perdería una en caso de ser falso. En cambio, mediante la decisión de probar se seguiría salvando una vida en caso de ser el verdadero Grial mientras que se perderían dos en caso de ser falso –Indy por probar el Grial y su padre por no encontrar remedio. Para un entretenimiento de aventuras, el arrojo del profesor Jones puede llegar a ser muy emotivo, la línea que separa el arrojo de la temeridad puede ser muy delgada, pero un directivo que no esté loco de atar se cuidaría mucho de encomendarle un proyecto al famoso aventurero del sombrero y el látigo.

En el anuncio anterior, planteé un dilema. Ahora que disponemos de una poderosa herramienta de análisis estratégico, vamos a reconsiderarlo a luz de la misma. Si cruzamos las dos estrategias de cada uno de los dos jefes de proyecto (invertir en más recursos para recortar el plazo o no hacerlo), y asociamos los resultados que obtiene cada uno para los diferentes cruces (desviación en plazo, negativa si excede el presupuesto y positiva en caso contrario), se obtiene la siguiente tabla:


¿Existe una estrategia clara para ambos jefes de proyecto? Como finalizaba el anuncio anterior, si fueras uno de los jefes de proyecto, ¿qué harías?, ¿recortarías el plazo o no? Se aceptan sugerencias.

16 agosto 2006

Dilema

Imagina que la empresa para la que trabajas ha resultado adjudicataria, junto con otra, de un contrato para la construcción de los tanques de almacenamiento de una futura planta de regasificación. Para llevar a cabo la ejecución del proyecto ambas empresas han creado una UTE, aunque en la práctica se han repartido a partes iguales el número de tanques de manera que a ti te han encargado la dirección de una parte del proyecto, mientras que de la otra parte se encargará otra persona de la otra empresa. Los dos jefes de proyecto partís con planes de proyecto y presupuestos idénticos, aunque disponéis de libertad a la hora de tomar decisiones sobre caca uno de vuestros respectivos proyectos. Por otro lado, los costes de cada proyecto están desglosados en dos partidas: una que imputa directamente a cada uno de los proyectos y otra que imputa a una partida presupuestaria de la UTE común a los dos proyectos. Una vez finalizados los dos proyectos, el importe de esta partida presupuestaria común se dividirá en dos partes iguales deduciéndose cada una de ellas del margen bruto alcanzado por cada uno de los dos proyectos.

Después de leer el plan de proyecto que te han entregado, el mismo que le han entregado al jefe de proyecto de la otra empresa, te percatas de que hay una bonificación por parte del cliente de 30.000 € si la mitad de los tanques están finalizados con un mes de antelación, y de otros 30.000 €, a sumar a los anteriores, si son todos los finalizados con antelación. Utilizando el método CPM llegas a la conclusión de que necesitarías 40.000 € para poder recortar un mes el plazo de tu proyecto, con lo que excederías en 10.000 € el presupuesto del mismo, hecho que no sería visto con buenos ojos por tus superiores. Pero espera un momento, también te das cuenta de que esos 40.000 € extra se podrían colar en la partida presupuestaria común de forma que al final del proyecto solo se te imputaría la mitad. Y 20.000 € menos los 30.000 € de bonificación, por finalizar con un mes de antelación, supondría haber finalizado el proyecto ¡10.000 € por debajo del presupuesto! Menudo tanto frente a los superiores. Pero resulta que la rapidez de tu argumento había pasado por alto el hecho de que para ello el otro jefe de proyecto no debería también intentar recortar el plazo, porque en ese caso lo dos gastaríais 40.000 € extra de la partida común de manera que estaríais como al principio, excediendo en 10.000 € el presupuesto. Porque si yo lo hago y el otro no lo hace, él se come 20.000 € que harían sobrepasar precisamente en esa cantidad su presupuesto, mientras yo me cuelgo las medallas. No, no. Piensas que es mejor no hacer nada. Es lo mejor para los dos. Pero entonces… ¿y si el otro, pensando que yo he llegado a esta conclusión, decide entrar a reducir el plazo y así llevarse los méritos? Menudo lío. ¿Y tú que harías?

10 agosto 2006

Corrección de errata

En el libro Excel ofrecido en el anuncio del pasado 4 de agosto, que contiene un cuestionario de autoevaluación sobre estilos de gestión, había una errata que ha detectado Santos -ver los comentarios del anuncio. El error ya ha sido subsanado y el libro de Excel sustituido, de manera que ahora sí que muestra los resultados de la forma gráfica correcta. Pido disculpas a todos aquellos que ya lo habían realizado y cuyos resultados gráficos no eran los correctos. Gracias Santos por el detalle.

09 agosto 2006

El conejo y los stakeholders

Hoy me he llevado una grata sorpresa en mi visita al sitio Web de Improbable Research, lugar al que ya hacía tiempo que no accedía y que, también para mi sorpresa, se ha reconvertido en parte en un blog. Bueno, quizás no debería ser tan sorprendente. Pues decía, respecto a la primera sorpresa, que me he encontrado con una antigua fábula que circulaba por los ambientillos académicos de medio mundo en mis tiempos de doctorando, e imagino que lo seguirá haciendo. Me refiero a la historia del conejo doctorando. Como toda gran fábula que se precie, aunque la historia fluya en un contexto determinado, en realidad son historias universales. Voy a permitirme la licencia de re-narrarla dentro del contexto de los proyectos. La historia dice así:

En la jungla de los proyectos, un pequeño conejo se tropieza con un lobo.
- ¿Qué hace un conejo por aquí? –le dice el lobo lleno de apetito.
- Estoy dirigiendo un proyecto muy importante – le contesta el conejo.
- ¿Y de que va ese proyecto tan importante?
- Sobre la superioridad de los conejos sobre los lobos.
- Ja ja, ¿estás de broma?
- Si no te lo crees ven a mi despacho.
Y ya nunca más se supo del lobo.

Pasado un tiempo, el conejo se encuentra con un tigre en la jungla de los proyectos. Preguntado nuevamente el conejo sobre lo que está haciendo en un lugar tan peligroso, éste le responde al tigre que “dirigiendo un proyecto sobre la superioridad de los conejos sobre los tigres”, y si no le cree que se venga con él a su despacho y se lo mostrará gustosamente.
Y ya nunca más se supo del tigre.

Después de sus merecidas vacaciones, el conejo, de vuelta a la dura jungla de los proyectos, va y se encuentra con un zorro. Al conejo no le queda más remedio que invitar al zorro, que no se cree eso de la superioridad de los conejos sobre los zorros, a su despacho para enseñarle su plan de proyecto. Una vez dentro del despacho del conejo, el zorro ve un pequeño montón de huesos de lobo y, a su lado, otro no tan pequeño de huesos de tigre. Y a su lado, detrás de una gran mesa, sentado en un sillón de ejecutivo, un león. Sobre la mesa, un pequeño cartel advierte del cargo de su ocupante: Director ejecutivo, patrocinador del proyecto.

Moraleja: no importa de qué vaya el proyecto que estás dirigiendo sino el poder que tenga su patrocinador.

07 agosto 2006

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

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

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

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

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

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


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

04 agosto 2006

El planificador, el administrador, el bombero y el oportunista

Dos peligros amenazan al mundo, el orden y el desorden
Paul Valéry

Son las 10 de la mañana de un lunes cualquiera, en un lugar indeterminado del sur de Ontario, Canadá. A Sergio aún no le ha dado tiempo de sufrir los síntomas del jetlag, ni puede que le de tiempo ya; el marrón que se le ha venido encima ya se ha encargado de borrar cualquier amago de síntoma de trastorno horario. El verdadero trastorno es que, después de haber realizado un viaje relámpago para coordinar la instalación de los sistemas de información de unas obras públicas, resulta que no puede ser porque faltan algunos stakeholders por firmar la aprobación del inicio de la instalación. Maldita burocracia, se lamenta para sí Sergio. Tan sólo ha podido echarse poco menos de tres horas en una cama, después de haber llegado alrededor de la medianoche anterior al aeropuerto internacional Pearson, coger un coche de alquiler y dirigirse a un hotel cercano al aeropuerto. Y ahora allí se encuentra con unas decenas de kilos de cable y material electrónico, preparados para ser desplegados, frente al Project Manager de la gestora que les ha subcontratado, un anglosajón amante de las policies. Que sí, que está so sorry pero que no puede dar su aprobación sin las firmas de todos y cada uno de los stakeholders, que la metodología es la metodología y que lo que Sergio pretende no está contemplado en las Project Policies. En fin, que está very sorry, pero ahí no monta ni el tato. May be by the end of the week. Pero para entonces tiene que estar cogiendo otro avión que lo llevará a México donde tiene el kickoff de otro proyecto. Si no comienzan a montar ahora, la semana que viene no va a poder ser aunque estén estampadas las dichosas firmas. Bueno, ni durante una larga temporada a menos que envíen a otro desde Madrid, y no se le ocurría quien podría ser. Las diferentes alternativas circulan a velocidad de vértigo por el entramado neuronal de Sergio. Y dicha carrera cobra especial intensidad frente al hecho de que el Project Manager se marcha después del lunch y no vuelve hasta precisamente el viernes. Todo el personal que en este momento copa el proyecto es de la compañía de Sergio, y a sus órdenes.

El viernes, cuando el Project Manager regresa a la obra y va a comunicarle que el próximo martes ya tendrá el visto bueno para comenzar la instalación, se encuentra con que la misma está prácticamente finalizada y tan sólo restaría realizar los ajustes preliminares. En realidad, la presencia de Sergio ya no es necesaria desde el día anterior y, de hecho está preparándose para coger el avión a México según lo previsto. Atrás se deja al Project Manager lamentando que no se hayan respetado las policies y todo eso. Durante los siguientes días va a haber fricciones con la gestora del proyecto, pero Sergio se va tranquilo pensando en que al final pesará más el hecho de haber evitado un retraso importante en el proyecto que de haberse saltado una pequeña regla sin más trascendencia que el del funcionamiento interno.

En el momento en que el avión de Sergio está despegando es viernes por la tarde en Madrid. “Lo que mal empieza mal acaba”, piensa para sí Juan mientras repasa mentalmente los acontecimientos sucedidos a lo largo de la semana. Juan está dirigiendo un proyecto de migración de la base de datos de una compañía aseguradora; y nunca ha llevado bien esa terca manía de la realidad de ponerle obstáculos al plan previsto. Con el notición que le acaba de llegar, los retrasos en las entregas de los nuevos formularios que le comunicaron a principios de semana acaban de pasar a un plano secundario. Una de las aplicaciones de la aseguradora no es compatible con la versión, la última, elegida de la nueva base de datos. En realidad Juan está bloqueado: con los retrasos aún puede ir lidiando con el plan de proyecto en la mano. Pero esto… Ni tan siquiera está contemplado en el plan de proyecto. En situaciones como ésta siempre se acuerda de aquel jefe de proyecto que había en su anterior compañía que casi siempre se las arreglaba para ir a salto de mata en los proyectos. Era un buen apagafuegos, a pesar de que muchos de esos fuegos no hubieran sido tales si hubiera tenido más capacidad de previsión. No le gustaba planificar como a él, pero en esta situación seguro que podía echarle un cable…

En los dos relatos anteriores se encuentran cuatro personajes que responden respectivamente a uno de los cuatro arquetipos que dan título a este anuncio. Dejo como un entretenimiento para el lector que averigüe quien es cada cual. Lo que nos interesa de aquí en adelante es que son cuatro atributos de la gestión en general, y de los proyectos en particular, muy importantes. A lo largo del curso de un proyecto se van a presentar diferentes situaciones en las que hay que responder de alguna de estas maneras. Al inicio de un proyecto es muy importante planificar el curso del mismo y, siempre que el acontecer del mismo siga más o menos ese curso, no hay nada que nos indique que haya que abandonar esa visión. Ahora bien, Murphy siempre se reserva el derecho a aparecer allí donde menos se le espera. Y cuando eso ocurre de poco nos sirve aferrarse ciegamente al plan de proyecto; y digo ciegamente porque a pesar de ello el plan de proyecto siempre es una herramienta de utilidad aún en estos casos. Pero también está claro que en ellos también hay que improvisar y responder con cierta rapidez, antes que la mantequilla de Murphy se extienda manchando el resto del proyecto. En realidad estas dos actitudes, planificador y apagafuegos, son los extremos opuestos de una dimensión que mide el grado de actividad en un proyecto: el planificador tiene un comportamiento proactivo, mientras que el apagafuegos lo tiene reactivo. No hay un comportamiento mejor que el otro, simplemente depende de lo que requiera la situación en cada momento.

Por otro lado, las reglas y normas en un proyecto, en forma de una metodología, son importantes para dotar de una estructura organizativa al proyecto sin la que sería imposible realizarlo con éxito. Pero también está claro que seguir a rajatabla esta burocracia sin inteligencia en ciertas ocasiones, puede afectar de forma negativa al proyecto y conviene recordar esa máxima que dice que toda regla tiene su excepción. En este caso estas dos actitudes, administrador y oportunista, también son en realidad los dos extremos de otra dimensión que mide el grado de organización en un proyecto: el administrador es sistemático mientras que el oportunista no. Nuevamente no hay un comportamiento mejor que el otro, depende de la situación. En principio no debería haber razones para no serlo, es la garantía de coherencia, pero hay momentos en que, si no me salto una regla, el proyecto puede llegar a un punto muerto o, simplemente, se pueden desaprovechar oportunidades que surgen, y no previstas, que pueden redundar en beneficios para el proyecto y/o la organización. En última instancia una sistemática cambia porque cambia el entorno. Y gracias a que el entorno cambia, cambian las organizaciones, surgen nuevas oportunidades que permiten la creación de nuevos negocios, y aquellas organizaciones que no adaptan su sistemática al nuevo entorno perecen. Hay que ser mínimamente sistemático como para no diluirnos en el caos, pero no lo suficientemente rígido como para no adaptarnos con flexibilidad a los cambios.

De la misma manera que no hay un comportamiento mejor que otros, sino uno más adecuado en cada momento, tampoco debería haber perfiles con cada una de estas características. Si bien siempre existirá una componente innata de alguna o algunas de estas características dentro de nosotros, es también el medio organizacional en el que se desarrolla un proyecto el que dicta muchas veces el comportamiento de gestión. Un proyecto, dadas sus especiales características de temporalidad, novedad e irreversibilidad, es el terreno ideal para que se den todo tipo de situaciones, por lo que es importante que un jefe de proyecto esté preparado para adecuar su comportamiento a cualquiera de estas situaciones descritas. Para evaluar nuestros puntos fuertes en esta materia y aquellos aspectos susceptibles de mejora, adjunto un libro de Excel con un cuestionario de autoevaluación. El resultado es un gráfico de tipo radar como el de la figura siguiente, que permite comparar los cuatro estilos entre sí.

31 julio 2006

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

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

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



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

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

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

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

30 julio 2006

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.