28 abril 2006

Murphy trabaja en mi proyecto... Maquiavelo también

Ya hemos visto cómo nuestro amigo Murphy, el portador de la incertidumbre, se pasea de forma impune por cualquier rincón, por recóndito que éste sea, de nuestro proyecto. Afortunadamente no es un hecho que no se pueda gestionar si entendemos bien cómo afecta la variabilidad a un proyecto, y disponemos de herramientas adecuadas para organizarnos. Que las hay, y de las que algunas de ellas hemos tratado en este blog. Por otro lado, cualquiera que se haya fogueado mínimamente durante su transcurso por la vida, y por el mundillo de los proyectos en particular, sabe que cualquier teoría tiene poco valor en sí misma en el mundo de las relaciones sociales. Y no hay que olvidar que un proyecto es algo que, en última instancia, acontece en un medio social regido más por rituales que por ideas. No quiero decir con esto que las herramientas no sirvan para nada, sino que necesitan de algo más para que se les pueda sacar todo el partido posible.

Como nos muestra William Golding en el “Señor de las moscas”, aquél que gestiona mejor los rituales que las ideas es el que al final se lleva el gato al agua. No basta con creer que se tiene razón, hay que hacer parecer que se tiene razón, que no es lo mismo. Cuántas organizaciones se han quedado en el mero intento de implantar una metodología de gestión por proyecto, a pesar de que era muy buena, estaba compuesta de técnicas y herramientas de software muy avanzadas, etc. Nadie ponía en duda que era la metodología adecuada. Sin embargo nunca nadie la utilizó, creó confusión y, al final, incluso el rechazo. Se falló en la gestión del ritual. Apelar a la buena voluntad de las personas para que lo acepten de forma automática puede ser un bonito ideal, pero parafraseando a Edward O. Wilson, el padre de la sociobiología, para la especie equivocada. La naturaleza humana no es muchas veces como nos gustaría que fuese -es muy recomendable a este respecto la lectura de “La tabla rasa” de Steven Pinker.

Como hace Guillem Bou en un momento de su libro “Comunicación persuasiva”, voy a suponer mediante un acto de fe que los lectores de este anuncio tienen buenas razones. Entonces les recomiendo algunas lecturas para que puedan ahondar en la parte que supuestamente les faltaría. Estos libros son, aparte del de Guillem Bou citado antes, “Las 48 leyes del poder” de Robert Greene y “Maquiavelo y Borgia” de José Luis Sanchis.

27 marzo 2006

Tampoco hay que cebarse con la incertidumbre


Ha pasado ya un largo periodo de tiempo sin que haya publicado un nuevo anuncio. Una consecuencia positiva de ello es que me ha permitido realizar una mirada retrospectiva, sosegada y distante de lo que se lleva publicado hasta el momento. Y a lo largo de esa revisión uno se encuentra con que prácticamente todo lo publicado en el blog tiene que ver con la incertidumbre. Quizás porque tenga mucho que ver con las causas de fracaso de los proyectos...; quizás porque en el fondo los proyectos no son más que empresas temporales altamente especulativas, y para una buena gestión de los mismos debamos reservar algunos esfuerzos para gestionar la incertidumbre... Quizás ha llegado el momento, también, de efectuar algunas puntualizaciones al respecto.

En última instancia un proyecto no es más que un conjunto de actividades que se deben realizar con el fin de lograr unos resultados dados. Gran parte de la incertidumbre en un proyecto proviene de la imprecisión de las asunciones en que nos hemos basado para definir dichos resultados y actividades. Para ser más precisos, de cómo de no tan bien definidos están por un lado los objetivos del proyecto y, por otro, los métodos para alcanzar dichos objetivos. Porque no debemos olvidar que cualquier plan de proyecto está basado en asunciones. Y esto es así porque a mayor número de actividades en las que descomponemos un proyecto y/o a mayor grado de interdependencia entre las mismas, la capacidad de predicción se ve mermada a medio y largo plazo.

La experiencia muestra que el desasosiego que genera esta incapacidad de predicción ilimitada tiende a producir una respuesta pendular con dos extremos bien definidos, y que influyen muy negativamente en el curso de cualquier proyecto. En un extremo nos encontramos con la actitud típicamente resabiada del jefe de proyecto que llega a la conclusión de que planificar el curso de un proyecto no sirve para nada. Esta actitud no tiene nada que ver con el nivel de conocimientos o la competencia de quien la posee, nos podemos encontrar con gente muy inteligente y experimentada que cree firmemente en dicha aseveración. Esta concepción es errónea ya que nuestra incapacidad de predecir el futuro no justifica de ninguna manera que planificar sea una pérdida de tiempo: de hecho, mediante la planificación evitamos una gran cantidad de problemas adicionales que en otro caso constituirían un lastre para el proyecto. Existen otras manifestaciones derivadas de esta actitud, tales como “conozco mi trabajo y no necesito planificarlo” o “no puedo desperdiciar mi tiempo planificando”. No son más que muestras de una línea de pensamiento corta de miras y, a veces, rayando lo estúpido. No vamos a profundizar más en este extremo porque, en definitiva, no es más que la actitud de quedarse con los brazos cruzados y esperar a verlas venir. Nosotros vamos a optar por una actitud más proactiva, aunque no exenta de problemas que sí merecen la pena se analizados.

En el otro extremo del péndulo nos encontramos con la actitud de intentar abarcar la complejidad de los proyectos y nuestra limitada capacidad de predicción con análisis más concienzudos, introduciendo un nivel mayor de detalle con la falsa esperanza de acercarnos a la precisión absoluta. Pero la realidad es muy terca y la precisión de nuestras predicciones es limitada. Y es entonces cuando viene, no ya la parálisis por el análisis, no hacer nada en este caso no sería tan malo después de todo, sino la introducción innecesaria de más complejidad e incertidumbre en el proyecto. Como decíamos al principio, cualquier plan de proyecto está basado en asunciones más o menos frágiles, no importa cuan detallado sea este plan. Uno estaría tentado a pensar que un mayor nivel de detalle y estructuración en actividades, y un concienzudo análisis de todo ello, hará que el proyecto en su conjunto irá bien. Pero cualquier jefe de proyecto experimentado sabe que este principio no es correcto. Al final lo único que hace es generar un ruido que envuelve al proyecto como una densa niebla que no deja ver el verdadero meollo del asunto. Y lo que es peor, como toda acción que tiene una reacción acorde a su magnitud, empuja el péndulo hacia el otro extremo con lo que volvemos al punto de partida.

Un error muy común que se comete es generar planes de proyecto más precisos que la propia precisión de las asunciones. Ello se debe al confundir incertidumbre con imprecisión. La imprecisión en las asunciones genera incertidumbre con el tiempo. Un ejemplo se da en un proyecto de desarrollo de software cuando tenemos unos subsistemas a realizar hacia el final del proyecto, y sobre los que aún no se dispone de un análisis funcional detallado en el momento de efectuar el plan del proyecto: no es nada efectivo malgastar tiempo definiendo con detalle las actividades a realizar en dichos subsistemas. Por mucho detalle que intentemos dar no vamos a reducir la incertidumbre porque en realidad es una cuestión de precisión. La ridiculez de este intento la ilustra muy bien la anécdota del empleado de un museo que decía a los visitantes que el dinosaurio que estaban viendo tenía 90.000.006 años y tres meses de antigüedad. Preguntado al respecto, respondía que cuando lo contrataron para el puesto le dijeron que tenía 90 millones de años; pero de aquello hacía ya seis años y tres meses.

Hoy en día disponemos de técnicas analíticas y paquetes de software muy potentes que ofrecen una inestimable ayuda en la gestión de los proyectos. El verdadero problema sobreviene cuando nos extralimitamos en su uso, como utilizar un cañón para matar moscas o un micrómetro para medir el perímetro de la isla de La Gomera.

11 noviembre 2005

Cómo gestionar la incertidumbre en los proyectos (2)

En este segundo anuncio de la serie se analiza el efecto que el hecho de no comunicar y aprovechar las finalizaciones de las tareas antes del tiempo previsto provoca sobre el plazo real de los proyectos. Si no se tiene en cuenta este hecho, los plazos estimados son siempre más optimistas que la realidad. Todo esto se ilustra en el siguiente libro de trabajo de Excel.

03 octubre 2005

Cómo gestionar la incertidumbre en los proyectos (1)

En el anuncio anterior se introdujeron los efectos que produce la combinación de la variabilidad en los procesos y la interdependencia entre los mismos. Un claro ejemplo de un escenario donde se da esto es un proyecto.

Este anuncio es el primero de una serie en los que vamos a profundizar sobre estos hechos que, en caso de no ser tenidos en cuenta, y de hecho no lo son, provocan predicciones sobre la marcha de un proyecto que nada tienen que ver con lo que luego es su realización. ¿Nos suena esto? Espero que, a medida que vayamos leyendo los sucesivos anuncios de esta serie, y analizando los ilustrativos ejemplos que en ellos se incluye, nos vayamos percatando de que, según la forma tradicional de planificar los proyectos, no es de extrañar que en éstos se invierta más tiempo del originalmente previsto. Sencillamente no estamos haciendo bien las cuentas.

En este primer anuncio de la serie, concretamente en este libro de trabajo de Excel, se analiza el caso de la paralelización de tareas. Si hasta ahora habías pensado que el tiempo que requería la realización de dos tareas en paralelo (evidentemente ejecutada por recursos independientes) es el de aquella de mayor duración, espero que el análisis del libro de Excel socave profundamente esta creencia infundada. Quizás, cuando la duración de una de las tareas sea mucho mayor que la de la otra, esta creencia tenga algo de fundamento. Pero, cuando la duración de ambas tareas es comparable, esto ya no es así. Si quieres ver cómo esto ocurre, mira en el libro Excel mencionado.

20 septiembre 2005

Incertidumbre e interdependencia

Durante los últimos años la influencia que el determinismo ha ejercido sobre nuestra forma de estimar se ha ido reduciendo paulatinamente. Cada vez más jefes de proyecto son conscientes de que las cuatro jornadas que, por ejemplo, se necesitan para realizar cierto análisis funcional no son más que un valor esperado. De hecho, mirando en los históricos de la organización, el jefe de proyecto comprueba que las duraciones correspondientes a, digamos, las 71 veces que dicho análisis se ha realizado siguen bastante bien una distribución lognormal de media 4 y una desviación estándar de tres cuartos de jornada. En el fondo estamos reconociendo que la incertidumbre está ahí fuera, que Murphy trabaja en nuestro proyecto.

Si bien esta actitud ya es un logro en sí mismo, tan sólo hemos recorrido una pequeña parte del camino. Las formas en que Murphy hace trastadas en nuestro proyecto son inescrutables. Hemos admitido y dado cuenta de las variaciones o fluctuaciones estadísticas a las que están sujetas las tareas de manera individual. Pero un proyecto consta de diversas tareas interdependientes entre ellas. ¿Qué diabluras se le pueden ocurrir a Murphy ante este aumento de la complejidad? ¿Cómo afecta un entorno no independiente, como puede ser un proyecto o una planta de montaje, a las variaciones o fluctuaciones estadísticas?

Como se ilustra en este libro de trabajo de Excel, no considerar los efectos de la interdependencia sobre las fluctuaciones estadísticas puede llevar a estimaciones totalmente fuera de la realidad. La interdependencia produce un sesgo en la variabilidad haciendo, por ejemplo, que los adelantos individuales no se aprovechen y sí se acumulen los retrasos. Este hecho es la causa física tanto de la aparición de cuellos de botella en las cadenas de montaje, como de que un proyecto termine irremediablemente fuera de plazo respecto de la estimación que no ha tenido en cuenta este hecho.

En sucesivos anuncios se mostrará el impacto de este hecho sobre nuestras estimaciones en proyectos. El ejemplo que se ilustra en el libro de trabajo de Excel de este anuncio está basado en el juego de los dados del capítulo 13 de “La Meta”, cuyo autor es E. M. Goldratt, creador de la Teoría de las Limitaciones.

06 septiembre 2005

Los efectos demoledores de la multitarea

En el anuncio anterior, titulado "todo es cuestión de incertidumbre", se sugería que una de las conductas para enfrentarse de forma correcta a la incertidumbre era la de evitar realizar varias tareas al mismo tiempo (multitarea).

¿Estas pensando que esta actitud va en contra de todo lo que nos han enseñado sobre productividad y eficiencia personal? Después de leer este artículo, es bastante probable que empieces a dudar sobre esa creencia. Reproducimos el artículo por cortesía de Tony Rizzo, Product Development Institute.

01 septiembre 2005

Todo es cuestión de incertidumbre

En el anuncio del pasado 2 de agosto, titulado "¿por qué fracasan los proyectos?" se postulaba la existencia de una causa común a dicho fracaso. Identificarla, decíamos, era clave para reducir el fracaso.

Un elemento común a la serie de preguntas planteadas acerca de los elementos sintomáticos de fracaso es la incertidumbre. Pero si la incertidumbre fuera la causa, todos los proyectos deberían fracasar ya que, en el fondo, la incertidumbre es una caraterística inherente a todo proyecto. Y, desde luego, aunque no sean muchos, existen proyectos que finalizan con éxito a pesar de la incertidumbre.

La verdadera causa no es, pues, la incertidumbre en sí misma sino la forma en que nos enfrentamos a ella. Como iremos mostrando en este blog, los métodos tradicionales tratan de eliminar la incertidumbre allí donde se encuentre. Este empeño no es menos estéril que el de Sísifo, subiendo la pesada roca a la cima de la montaña para después volver a caer rodando por su ladera.

El método de la Cadena Crítica, basado en la Teoría de las Limitaciones, propone los cambios que se deben hacer en la gestión de proyectos para gestionar de forma correcta la incertidumbre. Cambios como los siguientes:

  • Dejar de presionar a la gente a que se comprometa a finalizar las tareas individuales a tiempo, y sí a finalizar el proyecto a tiempo.
  • No provocar que la gente realice varias tareas al mismo tiempo (multitarea).
  • En organizaciones con múltiples proyectos, establecer prioridades para los proyectos e introducir los nuevos proyectos según el sistema e prioridades.
  • Utilizar el método de la Cadena Crítica para programar las actividades del proyecto.