19 de febrero de 2012

Dirección de Proyectos centrada en principios



A lo largo de la ejecución de un proyecto, el Director de Proyectos ha de tomar muchas decisiones, todos los días. Que estas decisiones sean correctas o no, dependerá, en gran medida, de lo eficaz que sea el Director de Proyectos, tanto en el plano personal como en el interpersonal. Voy a intentar explicar esto sobre un ejemplo real.


Uno de los tragos más amargos que yo he vivido como Director de Proyectos tuvo que ver con dos personas que no encajaban en un equipo. Estas dos personas tenían mucha experiencia en tecnología mainframe (un tipo de ordenador IBM con un sistema operativo propietario, la tecnología más extendida en los centros de datos de las entidades financieras hasta que comenzó a ser sustituido por los sistemas abiertos tipo Unix y Linux). Yo debía integrarles en un equipo de 8 personas expertas en tecnología Java, mucho más jóvenes, con una forma muy distinta de trabajar. 

Trabajábamos en las oficinas del cliente. Era este uno de esos proyectos en los que el alcance no está bien definido de antemano. En la etapa inicial hubo que replanificar muchas veces. El alcance cambió drásticamente porque ya no había que programar en el sistema mainframe, esto fue asignado a otra empresa, simplemente había que comunicarse con el mainframe a través de ciertas interfases. Los dos expertos en mainframe seguían siendo necesarios, pero dejaron de ser recursos clave.

Quizá no supe comunicarles bien este cambio en los objetivos. Acabaron pensando que el cliente se equivocaba y a mí me culpaban de no haber defendido la planificación inicial. Había otras actividades necesarias en el proyecto que requerían de su juicio experto, pero yo no lograba que ejecutaran trabajos distintos a los que inicialmente se habían planificado. Por lo que respecta a la integración con los expertos en Java, sencillamente no existió. Los de mainframe iban al comedor en horarios para no coincidir con los de Java, los de Java criticaban a escondidas a los de mainframe (les ponían motes), etc.

El problema estalló cuando el responsable de estas dos personas, de otra unidad de mi empresa, quería facturar a mi proyecto el 100% de sus horas, por un trabajo cuyo valor neto había sido nulo. Hubo correos, reprimendas, mala comunicación, y al final todo lo que yo había escrito sobre ellos llegó a su buzón. Y yo les tenía al día siguiente esperándome a las puertas de la oficina del cliente.

La discusión de más de 2 horas ya no la recuerdo bien. Mi postura era que dos buenos profesionales como ellos tenían que estar en mi proyecto, podían cambiar, adaptarse a las nuevas necesidades. Yo también podría conseguir que el equipo Java les hiciera un hueco: si yo se lo pedía, también cambiarían. Como pueden ver, por aquel entonces yo daba más importancia a la Tecnología que a la Sociología. Al día siguiente hubo otras 2 horas de discusión, esta vez los tres acabamos de peor humor. Al final de esa semana, por suerte para todos, por otras razones, el cliente decidió excluir del alcance todo lo que sonaba a mainframe. El lunes siguiente, estas dos personas ya estaban fuera del equipo.

Quiero pensar que hoy no cometería los mismos errores:
  • No debí suavizar el problema, debí haberlo afrontado desde el principio directamente con ellos, no al final, cuando explotó. Escalar el problema a su jefe fue un grave error. Aquí no apliqué el principio de la honestidad.
  • No debí tolerar la falta de respeto entre unos y otros, dentro del equipo. Debo confesar que yo tenía más apego a los expertos Java, mi equipo de toda la vida. En un mismo proyecto no debe haber dos equipos. No fui justo.
  • Debí haber utilizado los recursos que se me asignaron de manera más responsable. No debí haber permitido que perdieran el tiempo en mi proyecto, por si acaso luego hacían falta.

La decisión correcta, la que correspondía a esta situación, por el bien del proyecto, era liberar cuanto antes a los dos expertos mainframe. Yo tuve que haber tomado esta decisión de manera proactiva, sin dejarme influir por otras personas o circunstancias, considerando todos los factores y lo mejor para el proyecto. Esta decisión sé que es correcta porque habría estado basada en principios:
  • Los resultados habrían sido mejores para los afectados, para el cliente y para mi empresa. Yo también habría salido reforzado como persona eficaz, fortaleciendo así mis valores vitales más profundos.
  • Tener la sensación final de que a estas personas las eché del equipo, que me libré de ellos, es muy diferente a la sensación que habría tenido si hubiéramos tratado el problema y elaborado una solución con la que todos ganáramos. Mi relación posterior con ellos habría sido mucho mejor. 
  • En lugar de tener una experiencia penosa, me habría sentido cómodo con mi decisión.


8 comentarios:

  1. Extraordinario artículo. Ciertamente, se aprende más de los errores que de los aciertos. Por otro lado, gracias por un testimonio tan sincero, es difícil que se reconozcan los errores pero muy útil, para uno mismo y para los demás, que intentamos aprender.

    ResponderEliminar
  2. Buen artículo, sin embargo no estoy del todo de acuerdo,siempre es difícil intermediar entre personas, pienso en el Jefe de proyectos como un facilitador en la toma de decisiones, no como un dictador que al final impone su ley, en vuestro equipo todos y cada uno de los participes tienen su parte de culpa atacándose unos a otros en lugar de intentar colaborar y aprender los unos de los otros, es muy complicado intermediar entre personas que no son auténticos profesionales.

    Un saludo.

    ResponderEliminar
  3. Hola Jose... siempre tan nutritivos tus posts...

    En primer lugar te felicito por la franqueza y honestidad con que has llevado el tema. Me fascina leer una persona que acepta sus errores, los expone en la red para ayudar a otros y no le da verguenza aceptar que se equivocó...

    El mundo esta lleno de gente que se cree perfecta y vive buscando culpables en otras personas.

    Pero me parece que no deberias ser tan cruel contigo mismo. El PM tiene muchas responsabilidades, pero no todas. Si un programador no hace bien su codigo, el PM no debe ponerse a codear, sino a mejorar el proceso. O capacitar o motivar a ese desarrollador, o reemplazarlo por uno de mas seniority. Pero no podemos ver al PM como el hombre orquesta...

    ¿porque te digo esto?

    Bueno como podemos identificar muy facilmente los problemas tecnológicos, no es tan asi los problemas psicológicos o sociales. El deber del PM, es identificar el conflicto o riesgo. Y luego aplicar una solucion... pero no ponerse el a arreglarlo...

    En este caso creo que lo mas acertado hubiera sido intentar socializar al equipo y de fracasar buscar un consultor solucionador de conflictos (como Ingrid Astiz de fuerzatres.com).

    A nosotros nos encanta solucionar todo tipo de problemas, y solemos tener un ego muy grande. Pero tenemos que aprender que para trabajar en equipo hay que confiar en otros, y en que van a ser capaces de solucionar los problemas.

    Un PM tiene muchas responsabilidades, como mantener las copas llenas y que a nadie le falte nada. El peor PM que existe, es el que no hace nada y solo mira, pero tambien es un problema el PM que se hace cargo de todo.

    Al final siempre llego a la misma conclusion... todo es una cuestion de equilibrio (yin yang)

    Abrazo!

    ResponderEliminar
  4. Gracias Jose, muy buen articulo. Subscibo lo que dicen mis compañeros. Hoy en dia es dificil ver gente que reconoce sus errores publicamente... y como ha dicho también algun compañero, el PM es un facilitador, los miembros del equipo también tienen su parte de culpa. Una persona que pone motes a espaldas de un compañero, no está obrando bien, no es buen compañero. Y eso se aprende en el colegio, no hace falta sacarse el PMP...

    ResponderEliminar
  5. Hola Jose;

    Me ha gustado tu artículo, coincidimos en que se aprende de los errores y de esta manera así nosotros también podemos aprender con tu testimonio.
    El PMBOK el capítulo 9 habla de la gestión de RRHH, yo pienso por experiencia que en proyectos en los que el valor lo dan los RRHH, como los de desarrollo de aplicaciones, es muy importante la gestión de estos, por lo tanto aveces hay que ser mas psicólogo que PM, aunque realmente no sea esa nuestra tarea si queremos que el proyecto llegue a buen fin no nos queda mas remedio que dedicarle tiempo a esta tarea.
    Me he sentido identificado contigo, no al mismo nivel de la historia que cuentas pero si en conflictos internos entre miembros del equipo y no creo que haya una fórmula que aplicándola se puedan evitar. Si creo que la honestidad y la transparencia en la gestión de proyectos hace minimizar los riesgos con los RRHH.

    Un saludo, Jose.

    ResponderEliminar
  6. Que buen y gran artículo, felicitaciones!!! yo tuve un equipo que trabajaba muy bien, eran solo 2 personas, pero se llevaban de cine, hasta el punto de irse a vivir juntos. Uno de ellos se echó para atrás y a partir de ahí todo se fué al garete, no se hablaban entre ellos, dejaron de trabajar bien porque empezaron a discutirlo todo...... un desastre....
    Finalmente me tocó separar todas las tareas y dividirlas de manera que solo tuvieran que hablar conmigo y no entre ellos, fué la única solución que encontré, y finalmente salió el proyecto....

    Cuando elegí a la gente del equipo, ya te digo, eran uña y carne, y acabaron por un problema externo sin hablarse... eso no se puede predecir...
    Los PM intentamos hacerlo lo mejor posible siempre, y a veces nos comemos marrones que no tendríamos que comernos.
    Gestionar personas es mucho mas dificil que gestionar proyectos, así que ánimo, que ya habrá proyectos mejores y trabajadores mas profesionales.

    Saludos!
    Maruxa Cabezudo

    ResponderEliminar
  7. Luis Martínez23/2/12, 15:06

    Excelente artículo.
    Uno de los problemas de PM es la gestión de las personas. Quizás el más grave.

    Cuando es tu jefe, el dueño de la empresa, el que está ocasionando fricciones en tu equipo, puenteándote e intentando dirigir, aunque no tenga ni idea de proyectos o tecnología, porque su especialidad es finanzas, y un miembro de tu equipo sea su hermano, encima puesto a dedo, porque es 'su empresa' y 'hace lo que le dá la gana', y te deja en ridículo ante tu gente ... ¿cómo se resuelve éso?

    ResponderEliminar
  8. Hace algunos años publiqué este artículo en una revista que no recuerdo cual fue, pero que puede ser aplicado al tema que ha propuesto Sandra http://articulosmbc.blogspot.com/ el título es: El empresario PyME y la imagen de un buen capitan.

    ResponderEliminar