Archivo de la etiqueta: mejora continua

Cómo reducir los retrasos en los proyectos

Leí una entrada de un blog hace unos pocos días que me ha hecho reflexionar aquí. Siempre estamos hablando de cómo planificar proyectos y escribimos sobre ello como si hubiera alguna receta mágica que nos permitiera hacer mejor esa planificacion desde el primer momento. Sin embargo, también hablamos de que las metodologías ágiles de gestión de proyectos nos ayudan a realizar el proyecto sin confiar en tener la información completa desde el incio y que las metodologías waterfall tienen carencias y plantean dificultades para el entorno actual. Nos parece que es mejor fallar pronto, fallar barato y redirigir el proyecto que empeñarnos en un inmenso esfuerzo de planificación para, al final, tener también que hacer ajustes en el proyecto durante la ejecución. Así que vivimos en esta contradicción. ¿Es posible reducir los retrasos en el proyecto en la etapa de planificación si asumimos la idea de que, por su naturaleza, esa etapa contiene errores e imprecisiones?

Y leyendo esa entrada que mencionaba, pensaba si lo que se propone allí es lo que queremos los lectores. Es decir, si es interesante la pregunta que planteaba el redactor, esa forma de retar al lector como si él ya supiera la respuesta. Como si hubiera un nuevo local de moda y alguien hiciera la pregunta de si todavía no has estado allí provocando en alguna ocasión el sonrojo del interpelado por temor a no estar a la altura del inquisidor. Reconozco que el titular está conseguido porque me hizo leer la entrada y pensar sobre el tema. Pero opino que no es lo que buscamos todos los lectores. Lo que algunos buscamos es que alguien no dé ideas frescas sobre cómo se hacen las cosas en otros lugares e intentar aprender de ellas. Y se me ocurrio proponer esta entrada en la que voy a hablar de cómo reducir el retraso en los proyectos.

Vayan por delante dos cosas. En primer lugar, y siento decirlo, que no tengo la respuesta, entendiendo como respuesta un argumento único que se aplicaría en todos los casos. Lo aviso por si queréis dejar la lectura de la entrada y no haceros perder más tiempo. En segundo lugar, voy a decir que estoy de acuerdo en que en los retrasos tienen mucho que ver el síndrome del estudiante, la Ley de Parkinson y la Ley de Carlson. Esta última, por cierto, no la conocía hasta ahora con ese nombre. Entonces, os preguntaréis, ¿a qué esta entrada? El motivo es que el análisis me pareció superficial y que creo que no cubrimos bien el apartado de lecciones aprendidas de los proyectos.

Para reducir los retrasos en los proyectos, no hay más remedio que hacer proyectos y aprender de ellos. Es decir, trabajar a fondo el tema de lecciones aprendidas. Sobre esto, he oído hablar mucho pero no he visto ejemplos de cómo llevarlo a la práctica. Así que os voy a proponer un esquema para recoger vuestras lecciones aprendidas y sacarles partido.

  1. Recoger diriamente las incidencias que hayan provocado retrasos en el proyecto estimando la duración del retraso. Si es posible, convertir el retraso en unidades monetarias para conocer el impacto sobre la cuenta de resultados. Es posible que un retraso largo en la etapa de planificación tenga un coste menor que un retraso más corto durante la ejecución en los momentos en que tenemos comprometido el máximo de recursos.
  2. Clasificar la causa inmediata del retraso. Para ello, es necesario crear un listado estandarizado de causas inmediatas. Si no se tiene ninguno, recomiendo empezar por los procesos de PMBoK asumiendo que cada proceso mal ejecutado puede dar lugar a algún  defecto como puede ser el retraso en un proyecto. Según se gana experiencia, se pueden incorporar más causas inmediatas y agrupar bajo un mismo epígrafe aquellas que se demuestra que tienen poca incidencia.
  3. Realizar un gap analysis para conocer la diferencia entre dónde estamos y dónde queremos llegar.
  4. Hacer un análisis ABC para enfocar nuestos esfuerzos en aquellos procesos que provocan más incidencias y decidir cómo cubrir la brecha descubierta en el paso anterior.
  5. Hacer un análisis de causas básicas en aquellas áreas que se ha decidido trabajar.
  6. Planificar las medidas a tomar.
  7. Implementar las acciones y evaluar su impacto.
  8. Estandarizar.

Espero que esta sistemática sea útil aun cuando sea para trabajar y esperar frutos a medio plazo más que para conseguir resultados en ese proyecto en el que estás trabajando ahora. ¿Os atrevéis a proponer en los comentarios otras maneras de mejorar el resultado de vuestros proyectos?

También espero que esta entrada ayude a complementar la del blog de BeiNN y, desde aquí, les saludo y agradezco por darme esta idea sobre la que escribir.

Cuando el project management no es suficiente.

A menudo, tenemos la tentación de identificar el project management con un conjunto de técnicas y procesos. Igual que los sistemas de calidad. Y nos esforzamos mucho en conseguir que las técncias y procesos se apliquen y sus indicadores alcancen los valores objetivo. Pero voy a dar unos resultados publicados por Standish Group en 2009 respecto a datos de 2008:
  • El 32% de los proyectos finalizaron con éxito.
  • El 24% fallaron, es decir, se abandonaron o, una vez finalizados, nunca fueron utilizados.
  • El 44% tuvieron problemas de plazo, costes o reducción del alcance.
Bien es cierto que esta empresa se dedica a las TIC y que no se pueden extrapolar resultados a otras industrias. Si estos resultados son buenos o malos, lo podemos saber por comparación con años anteriores. No voy a ser muy exhaustivo pero los resultados anteriores fueron de 28% de proyectos exitosos en 2000, y 35% en 2006. Sé que estos números son demasiado gruesos para poder hacer un buen análisis pero, con todo lo que se supone que hemos trabajado en la mejora de procesos en esos 8 años, ¿cómo explicamos que la mejora sea tan escasa y que, incluso, haya habido un retroceso en los resultados?
En cuanto a los proyectos con problemas, el panorama es similar: 49% en 2000, 46% en 2006 y 44% en 2008. Aquí se aprecia mejora pero me parece muy escasa para el esfuerzo que se está haciendo por parte de asociaciones de project management, consultores y project managers.
Dicen que la crisis ha golpeado fuerte. Para mi, eso explicaría los resultados de los proyectos que han fallado puesto que fallo, entre otras cosas, incluye abandono y con la situación vivida me temo que haya ocurrido con muchos. Estos proyectos fueron 23% en 2000, 19% en 2006 y 24% en 2008.

Project manager preocupado por la evolución de sus resultados

¿Qué ocurre entonces? Bueno, os recuerdo que, en cualquier actividad, hay que tener un ciclo de mejora continua y analizar los resultados pero no sólo en términos de proceso sino en términos de resultados de negocio. Creo que algunos nos estamos enfocando en tener unos procesos robustos y bien acabados y no nos damos cuenta de que no nos están llevando adonde queremos ir. Cuando esto ocurra,  tenemos que ser capaces de buscar fuera de los límites de nuestros procesos. El mundo es muchas más cosas y mucho más complejo que nuestros modelos simplificados con los que pretendemos estandarizar nuestra forma de trabajo. Los project managers debemos ser ambiciosos y no conformarnos con unos procesos y procedimientos depurados sino buscar el ROI de nuestros proyectos.
Si los procedimientos actuales no son suficientes, no es que el sistema no funcione, es que necesita un ajuste. Por tanto, no dejemos que los directores y gerentes caigan en el desánimo por la apariencia de estancamiento y que tengan la debilidad de desmontar todo lo construido hasta ahora: démosles alternativas para mejorar los sistemas que actualmente estemos utilizando.
Cuidado: un buen proceso no es garantía de un buen resultado de negocio pero tiene que ayudar. Si no lo hace, busquemos la mejora para obtener el ROI