Un estudio del Project Management Institute (PMI) indica que 1 de cada 5 proyectos fracasa debido a problemas en la comunicación: un "Communication Breakdown".
En este post resumiré el estudio a la vez que describo mi adicción a Led Zeppelin. ¿Por qué? Si te interesa, sigue leyendo.
Eso me ha pasado varias veces con el Communication Breakdown de Led Zeppelin.
La última vez ha sido recientemente leyendo un informe del PMI en el que habla del impacto de los problemas de comunicación en la gestión de proyectos.
"Communication breakdown
It's always the same
I'm having a nervous breakdown
Drive me insane!"
White Paper del Project Management Institute (PMI)
- El 80% de los proyectos con "comunicaciones efectivas" cumplen los objetivos, sin ellas, sólo el 52%.
- El 70% de los proyectos con "comunicaciones efectivas" cumplen los plazos, sin ellas, sólo el 37%.
- El 76% de los proyectos con "comunicaciones efectivas" cumplen el presupuesto, sin ellas, sólo el 48%.
El resultado es evidente, si en tu proyecto IT tienes "Communication Breakdown", mejor tomar medidas o salir corriendo.
Para rematar las cifras, según el mismo informe del PMI, 1 de cada 5 proyectos falla debido a una comunicación inefectiva.
El documento concluye con un plan de acción para una comunicación eficiente que consiste en:
1.- Considerar la comunicación como una función estratégica:
"Salvo que enfoques la comunicación hacia los objetivos que deseas lograr, te arriesgas a centrarte en las tareas en lugar de en la foto completa de tus objetivos".
2.- Define el target:
"Si dejas a alguien fuera del grupo, el riesgo es que alguien que podía ser un apoyo se convierta en un detractor"
3.- Haz un esfuerzo de grupo:
"Todo el mundo debe participar en el proceso de comunicación si no quieres encontrarte un montón de sorpresas"
4.- Mézclalo:
"Integrando diferentes estilos de mensajes, tiempos, canales, las organizaciones se aseguran de que todo el mundo puede acceder a la información que necesitan, cuando la necesitan"
5.- Obtén opiniones del exterior:
"Esto trae objetividad al plan y asegura que el equipo del proyecto no se está engañando a sí mismo."
Communication Breakdown de Led Zeppelin
Desde ese momento hemos podido disfrutar de estos genios de forma individual, en reuniones (especialmente de Jimmy Page y Robert Plant) o al trío unido a Jason Bonham (hijo del batería original).
Respecto a Led Zeppelin poco más puedo decir sin caer en la evidencia. Es uno de los más grandes y han influenciado a todos los que posteriormente han hecho rock. Para mi, desde luego, un imprescindible.
Personalmente me ha acompañado desde mis años de estudiante en los que daba vueltas a la cassette con el bolígrafo. Años después me regalaron una colección completa en CD que guardo como oro en paño y rematé la historia comprando en una tienda de segunda mano de Estocolmo precisamente un vinilo original de ese primer disco de 1969. También he tenido la suerte de disfrutar de Plant en directo como telonero durante la gira del "Are you gonna go my way" de Lenny Kravitz en Barcelona.
Mi "Communication Breakdown" en IT
Muchas veces me he sentado frente a clientes, proveedores o compañeros y nos hemos dado cuenta de que algo había fallado. Los documentos estaban claros, aprobados y firmados pero, por alguna razón, la interpretación que cada uno hacíamos de ellos no era lo misma.
Lo peor es que en los proyectos de IT normalmente te das cuenta de esto cuando ya es demasiado tarde: pruebas integradas o de aceptación.
En este sentido, mi recomendación es clara, si el proyecto lo permite: apliquemos Agile. En Agile los riesgos de comunicación disminuyen: equipos conjuntos, comunicación directa y cara a cara, entregas de software cada pocas semanas en las que poder detectar y corregir malas interpretaciones, mayor flexibilidad para incorporar los estos errores, reflexión conjunta sobre los resultados y el proceso después de cada entrega, etc.
Destacaría la entrega periódica de software. Es díficil definir lo que alguien tiene en la cabeza, es difícil que otro lo escriba en un documento pero lo imposible es que este segundo tenga en la cabeza la interpretación y el contexto que tenía el primero. Ante un software funcionando no hay duda, es fácil comprobar si coincide con lo que pensaba. Si no coincide, cuanto menos tiempo y esfuerzo le hayamos dedicado, mejor.
Si trabajamos en Waterfall, no olvidemos Agile, muchas de las herramientas pueden ser utilizadas también en proyectos Waterfall.
No hay comentarios:
Publicar un comentario