Archivo de la categoría: Integration

Valor Ganado (EVM)- Lo que nadie te ha contado.

Deja un comentario

En el post anterior, os contaba cómo veo el uso de valor ganado y los beneficios que aporta en el control de los proyectos. Ahora, después de experimentar unas semanas con él, os voy a contar las cuestiones para las que hay que estar preparado para que la implementación sea un éxito.

Sobre la teoría de valor ganado, hay posts que llegaron antes que los míos y que la explican muy bien aquí, aquí y aquí. Sin embargo, lo que nadie cuenta es que el uso de valor ganado no es un camino de rosas. Para ayudaros a ponerlo en marcha rápidamente, os cuento los puntos a los que hay que prestar atención.

  1. Recursos para la gestión. Aunque sea sencillo, los informes de valor ganado hay que alimentarlos. Hay que preparar unas buenas plantillas de recogida de datos para que la su carga sea los más sencilla posible. Una vez creadas, hay que nombrar a alguna persona que rellene los datos.
  2. Disciplina. Dicen por ahí que son necesarios 21 días de práctica para crear un hábito. Otros piensan que no. No sé cuántos días serán necesarios. De lo que estoy seguro es de que hay que cuidar de nuestro nuevo sistema al principio, estar muy encima y preocuparse de que crezca sano. Dentro de la disciplina necesaria entra el que todos los responsables de paquetes de trabajo reporten sus resultados de una manera coherente.
  3. Hay que planificar. Esto es de lo más normal en el mundo de la dirección de proyectos. Sin embargo, en el mundo real, hay muchos que no lo hacen. Sin planificación, no es posible aplicar fórmulas de seguimiento.
  4. Medir el progreso real. Esto es lo que más quebraderos de cabeza me ha dado. Cuando se trata de unidades físicas bien definidas (m3, Tm, unidades, etc.) es bastante sencillo pero cuando se trata de composiciones complejas (una instalación eléctrica, una estructura metálica, etc.) no es tan fácil. Se pueden descomponer esas unidades en elementos sencillos. Con ello, mejoramos la precisión de la medida a costa de aumentar el trabajo de recogida de datos de campo. Esto último no lo considero deseable porque se pierde una de las ventajas más importantes de EVM y es su simplicidad lo que nos lleva al siguiente punto. Hay que crear una norma de cómo vamos a medir el progreso. Una de las clásicas es pedir a las personas encargadas de cada tarea que evalúen lo que han hecho y lo que consideran que les queda por hacer. Si no es posible, habrá que sacrificar precisión en aras de la simplicidad.
  5. El equilibro entre precisión y facilidad de gestión. Cada uno debe encontrar el punto en que se encuentra cómodo. Yo soy partidario de la simplicidad.
  6. Cuidar la delegación de paquetes de trabajo. Una de las cosas que me gusta de EVM es que se puede descomponer en muchos niveles y permite dar a cada responsable una herramienta de seguimiento de su paquete de trabajo. Esto hay que hacerlo bien, formando a las personas que van a gestionar cada paquete y cuidando de que el sistema mantenga la integridad.
  7. Control de cambios. Aquí no tengo un buen consejo aun. Ocurre muchas veces que el trabajo planificado no se corresponde bien con el trabajo real. Puede ser porque los medios asignados no sean exactamente los planificados, por ejemplo. Si el cambio no es grande, yo soy partidario de asignar al concepto presupuestado el coste real homólogo, es decir, el que haga la misma función para no complicar mucho el control de cambios ni caer en la hiperplanificación que, por razones por todos conocidas, ya no está de moda. En un ejemplo trivial, si preveo una grúa y luego utilizo para el mismo trabajo una carretilla elevadora, imputo el coste de la carretilla en el lugar que estaba destinado a la grúa.
  8. La previsión del coste incurrido final. Es una de las medidas que más interesan a aquellos que gestionan proyectos para hacer funcionar su negocio. Yo doy tres opciones que me definen un intervalo limitado por el menor y el mayor valor de entre los siguientes.
    • La primera opción de cálculo consiste en asumir que el trabajo pendiente por hacer se va a hacer al coste presupuestado. En ese caso, se suma al coste incurrido el coste planificado para el trabajo pendiente hasta el final del proyecto.
    • La segunda opción supone que el rendimiento del trabajo que queda por hacer va a ser el mismo que hemos logrado hasta el momento de hacer el cálculo. En ese caso, el coste esperado final sería el coste total planificado dividido por el CPI (Cost Performance Index).
    • La tercera alternativa es valorar nuevamente el trabajo que queda por hacer y sumar esta valoración al coste incurrido hasta el momento.

Y hasta aquí por el momento, ¿me daríais algún consejo más?

Cómo reducir los retrasos en los proyectos

Deja un comentario

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.

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

5 respuestas

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?

Is the client the project sponsor?

1 respuesta

This is a translation and an update from a former post written to help clarifying my position on the matter of several project managers and sponsors interacting among each other.

I would say there is no reason why we would establish the identity client=project sponsor. I show below a sketch I used as speaker during the event held in April 2011 by the Master in Project Management run by the University of Valencia. As a summary, what I think is that a client may have its own project sponsor while, simultaneously, the project supplier may have a different project sponsor too. Both roles, sponsor and project manager of each organization, might be performed by the same individual depending on project complexity.

The project sponsor on the client side usually asks a project manager to plan and execute a project based on a business case and by means of the Project Charter. Both sponsor and project manager hold accountable for delivering the needed project to solve the business case. This project manager will be in charge of the planning effort. As a result, at the proper time, requests for proposals (RFP) will be issued to suppliers and vendors. This will often happen via the company Purchasing Department which will contact the Sales Department of the supplier’s organization.

Once the supplier sends a proposal to the customer and gets its agreement, a sponsor on the supplier’s side should be appointed. The supplier’s sponsor should assign the project to one of the supplier’s project managers. They will write a Project Charter as part of their project initiation process. This Project Charter is different from the one written by the client since the client creates the project to solve his business case and the supplier should generate his project charter to support his own business. Of course this may become a source of conflict and confrontation. That is one of the reasons why it is important to gain alignment between client and supplier. From this moment, the supplier’s project manager starts his work to deliver the project result to his customer´s project manager.

Wheres the sponsor

Therefore this is the model I propose to explain relative position and interactions between sponsor and project manager. These roles are often confusing and lead to think that the client can only play the role of sponsor and supplier is always the project manager.