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?