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 y 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 erapa 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.

El tamaño importa

Mucho se ha escrito, al menos, en prensa, sobre las dificultades que ha tenido el consorcio GUPC en Panamá para terminar el proyecto del juego de esclusas del Canal de Panamá. Y, también, de las dificultades del Gobierno de Panamá para gestionar la relación con el contratista principal de ese proyecto. Se ha venido a decir que, por un lado, el consorcio se ha comportado como un fullero en una timba de póquer y, por otro, que el Gobierno ha adjudicado el contrato negociando al estilo de una feria de ganado.

No tengo intención de entrar en ello. Al menos, por el momento, porque creo que el caso da para aprender mucho sobre dirección de proyectos. Otra cosa es que luego se aplique. Lo que quiero traer al caso es considerar un factor a la hora de seleccionar proveedores para tu proyecto. Factor que no quiero decir que sea el principal pero sí puede ser interesante considerar al invitar proveedores a optar al contrato: el tamaño.

Cuando doy clase de dirección de proyectos, se me llena la boca hablando de la capacidad técnica, de los plazos que puede cumplir el proveedor, del precio (cómo no), de que aplique con las leyes y códigos en vigor, etc. Pero no menciono nunca el tamaño del proveedor.

Hubo un proyecto en que una empresa bastante grande tuvo que realizar la construcción de un edificio industrial. Acudió a pedir oferta a constructoras de renombre para seleccionar al contratista principal. No a las mayores, dedicadas a grandes obra de infraestructura, sino a sus subsidiarias que estaban en ese tipo de negocio. Y fue elegida una de ellas. Una de aquellas que dependía de la que, según escribí, pasó de ser una gran empresa a ser una empresa grande. El proyecto comenzó y defraudó mucho en cuanto a la calidad de la ejecución y la manera de llevarla a cabo: retrasos, contratistas no cualificados, violación de normas de seguridad, bajo nivel de compromiso… Todo esto podría haberse corregido pero el contratista principal no tenía ninguna intención de hacerlo. Se le llegó a amenazar con rescindir el contrato a lo que el contratista respondió deteniendo la obra y esperando el pleito y, por supuesto, dispuesto a no retomar los trabajos hasta que se resolviera. A final, sea como fuere, se solucionó la disputa y se acabó el proyecto.

Años después, esta misma empresa necesitó acometer un proyecto similar y acudió a un contratista que, aunque grande, era de tamaño bastante menor. El resultado fue muy distinto y el proyecto transcurrió suavemente. Por eso, el tamaño importa. Es necesario encontrar proveedores con la competencia técnica suficiente para los que el que el proyecto sea lo bastante importante como para comprometerse con él y admitan negociar en los momentos de conflicto. Si tu proveedor es mucho mayor que tú, puede querer imponer sus condiciones y tú tener que aceptarlas aunque te sean perjudiciales porque no tienes capacidad de negociación con él.

Por eso, a la luz del conflicto en la ampliación del Canal de Panamá, yo digo, ¿con quién podría negociar mejor el gobierno de Panamá en caso de disputa, con España o con Estados Unidos, de donde procedía el principal consorcio competidor de GUPC? ¿Puede haber influido esto en la adjudicación del contrato?

La práctica del ciclismo en la dirección de proyectos o cómo tener éxito entrando en el momento oportuno

Aunque me gusta el ciclismo como a mi amigo Emilio Callejón, e incluso lo he practicado, os voy a explicar cómo se puede aprovechar la práctica del ciclismo en la dirección de proyectos desde un punto de vista diferente al que él propone.

Cuando yo montaba en bicicleta, lo que más frenaba mi avance eran el viento, sobre todo, si soplaba en contra, y las pendientes. En cuanto a las pendientes, poco se podía hacer. Podías ir con amigos que te acompañaran y estar más animado en la línea propuesta por Emilio pero el esfuerzo es claramente individual. Sin embargo, en cuanto al viento, ahí sí hay posibilidad de recibir ayuda. Si pedaleas delante de todo el grupo, haces más esfuerzo pero apartas el aire de tus seguidores así que ellos se desgastan menos. Cuando el que va delante necesita un respiro, deja pasar a un compañero y él pasa a refugiarse en el grupo. El caso más claro de esto son las pruebas contra reloj por equipos.

Ciclismo crono equipo

¿Y qué tiene esto que ver con la dirección de proyectos? Os voy a decir qué es lo que me desgasta más en los proyectos que llevo a cabo: la incertidumbre. Encontrarme a menudo con situaciones inesperadas que necesitan que tome una decisión para continuar adelante. Después de este descubrimiento, me diréis que hacer una entrada dedicada a provocar que otro tome las decisiones no es muy interesante. A pesar de que esto da para escribir otra entrada porque tiene más interés de lo que parece, no voy a ir por ahí. Lo que quiero introducir es la posibilidad de hacer relevos en el proyecto. ¿Cuándo? Cuando tenga sentido. Y ahora es el momento en que os voy a relatar tres historias, como decía Jobs en su famoso discurso en Stanford. Como no puedo aspirar a tanto, me conformaré con contaros dos.

La primera es una historia de fracaso inicial y éxito final. Una persona fue asignada como director de proyecto para la construcción de una nueva fábrica en un país en el que no se tenía actividad previa. Tras construirla, debía ponerla en marcha y completar un pedido para un cliente durante varios meses de fabricación. Finalmente, una vez entregado el pedido, desmantelar la instalación. El director de proyecto tuvo que asumir tareas a las que no estaba acostumbrado (en este caso, la construcción de la fábrica y tratar con el cliente directamente) además de tener que organizar el trabajo de la fábrica con personal de un país que no conocía. El resultado final fue que el proyecto quedó bloqueado durante un tiempo en que no se podía completar la puesta en marcha a la vez que conseguir que el personal asumiera los procedimientos de trabajo que eran nuevos para ellos. La situación se solucionó enviando a un segundo director de proyecto cuyo objetivo era sólo poner en marcha la producción. Este último tuvo un éxito rotundo en dicha gestión y el primero cayó en desgracia (a mi modo de ver, de forma injusta). Si hubiéramos planeado un relevo ordenado, todos hubieran asumido que esa era una situación normal y hasta deseable y se hubiera gestionado con menos estrés.

La segunda es una historia similar a la anterior salvo que aquí sí se previó un relevo que salió mal. Se trataba de una nueva construcción hecha para albergar una nueva tecnología de producción necesaria para mantener futuros niveles de innovación en el producto fabricado a unos costes soportables. Implicaba cerrar la antigua instalación con sus líneas de producción. Se nombró un equipo para construir la nave y sus instalaciones (bastante numeroso y dotado de fondos suficientes), un equipo de puesta en marcha (bien dotado de personal y con fondos a costa de los presupuestos de la construcción) y el equipo de operaciones (equipos de producción con dotación completa y sin presupuesto de proyecto). El proyecto de construcción resultó bastante bien pero la puesta en marcha se encalló igual que en el caso anterior. El equipo de puesta en marcha no consiguió que el equipo de producción comenzara su labor con los rendimientos esperados. Las incidencias de la puesta en marcha junto con la dificultad que la nueva tecnología suponía para el personal de producción hicieron imposible superar la situación. Se nombró un nuevo jefe de producción al frente de la nueva instalación y éste resultó un éxito. Todo el crédito, para el segundo jefe de producción que recogió la cosecha sembrada por el primero que fue el que le apartó todo el aire que pudo al segundo. Nuevamente, si esto se hubiera vivido como algo natural, el proceso hubiera sido menos estresante. El segundo jefe de producción entró fresco a la cabeza del grupo, al modo de los ciclistas, cuando estábamos cerca de la meta. Y se llevó el premio.

Por eso, para este tipo de proyectos complejos, relativamente largos en los que son necesarias diferentes habilidades y conocimientos según la etapa del proyecto en la que nos encontremos, recomiendo planificar esto con tiempo y definir claramente las condiciones en que los equipos de una etapa deben dejar el proyecto para el siguiente relevo. Y, también, que parece mejor ser el segundo que el primero (esto ya lo lo dice Javier Megías con más gracia que yo).

¿Cuál vuestra experiencia?, ¿qué pensáis de esta forma de organizar proyectos?

La actitud lo es todo o, al menos, es mucho. Caso 34th America’s Cup.

Estamos en una de las competiciones deportivas reservadas para deportistas de élite. El nivel de los participantes es altísimo y cualquier pequeña ventaja nos puede dar la victoria en el campo de regatas. Somos el equipo anfitrión lo que nos da derecho a escoger el lugar en el que celebrar la disputa por el trofeo. Hemos elegido un lugar en el que tendremos todas las facilidades para estudiarlo y conocerlo con todo detalle; las corrientes, el clima, los vientos,… Tenemos a la afición a nuestro favor. No puede ser menos, estamos jugando en casa. Nuestro sponsor, Larry Ellison a través de Oracle, va a comprometer los fondos necesarios para la victoria. Somos afortunados de pertenecer al Oracle Team USA (por cierto, sin ánimo de hacer promoción porque no tengo interés al respecto, Oracle es la empresa detrás del conocido software de gestión de proyectos Primavera).

Oracle

Además de lo anterior, por la forma como se organiza la competición, todos los aspirantes deben pasar una criba en la que sólo puede quedar uno, el mejor de la competición llamada Copa Louis Vuitton, que se enfrentará con nosotros. Tendremos la ventaja de estudiar sus tácticas durante todas esas regatas, aprender de todo lo que les ocurra y anticipar nuestras respuestas para cuando llegue la gran final, la America’s Cup.

Ahora que ya he creado la expectación, me vais a permitir rebajar el clima. Me da por crear estudios de caso relacionados con el mar como este sobre Titanic. Bueno, me diréis que, en realidad, no es un caso sobre el barco pero no me negaréis que, al ver el título lo habéis pensado. En cualquier caso, sí tiene relación con el barco y el mar, aunque sea algo lejana. Llegados a este punto, ¿qué tiene que ver todo esto con la dirección de proyectos y con el título? No seáis impacientes, esperad al final.

Volvemos con el Oracle Team USA. Ya tenemos aspirante a la copa. Son unos tipos de una pequeña isla a orillas del Pacífico, el Team New Zealand. Será campeón aquel que alcance la victoria en 9 regatas. Pero resulta que la organización nos a ha cogido en algunas cuestiones que bordean el reglamento. Somos un pelín tramposos a qué negarlo; nos confiamos por jugar en casa y creíamos que el árbitro estaría de nuestro lado. Nos van penalizar con ¡dos victorias! Este es un fuerte revés: partimos con -2 pero podremos salvarlo.

Team NZ

Comienzan las regatas y estos neozelandeses demuestran ser buenos. Su barco vuela literalmente sobre el mar. Nuestro barco también pero menos, claro. (Os aconsejo que aprovechéis, aunque no seáis aficionados, para ver algunas imágenes espectaculares aquí). Los neozelandeses se han puesto por delante 6 victorias a 1 (os recuerdo que tenemos que llegar a 11 y ellos a 9 o, si se quiere ver de otra manera, 6 a -1) y, posteriormente, 8 a 3 (8 a 1 si aplicamos la penalización). Team New Zealand sólo tiene que vencer una vez más…

Qué momento más difícil para un equipo. ¿Cómo hemos llegado a este punto si lo teníamos todos a favor? ¿Qué respuesta se puede dar en esta situación? ¿Nunca os habéis visto al borde del abismo en vuestro proyecto? Es muy difícil superarlo y aún más con la presión del tiempo. No podemos dejarlo para dentro de unos meses; las fechas de las regatas, los hitos del proyecto, los deadlines, están establecidos y es imposible retrasarlos.

El equipo debió de estar muy afectado anímicamente y lo más natural hubiera sido darse por vencido y reconocer la superioridad demostrada por el aspirante. Pero ellos no lo hicieron. Aprendieron de sus errores, modificaron su barco (en este caso, dentro de las reglas de la competición), hicieron cambios en la tripulación y salieron a ganar todas las regatas. El resultado es que han vencido, a 22 de septiembre, en cinco regatas consecutivas dejando el tanteo 8 a 6. Habéis leído bien, cinco regatas consecutivas.

Y, ¿cómo se hace? No creo tener la respuesta pero desde luego, con actitud de ganar. Por eso la actitud lo es todo o, al menos, mucho.

Tanto si crees que puedes como si crees que no, estás en lo cierto.

Henry Ford.

Actualización.- Anoche, el Team USA ganó dos regatas consiguiendo empatar y completar una serie de siete victorias consecutivas. Hoy, 24 de septiembre, se decidirá el campeón en la última regata.

Segunda actualización.- Al final, en la última regata se ha impuesto el Oracle Team USA superando todas las dificultades. Enhorabuena a ellos por la determinación y afán de superación demostrados y al Team New Zealand por habernos hecho disfrutar de esta competición.