Trabajar como un equipo (I)

Al hilo del post que escribí la semana pasada sobre algunos proyectos que no fueron como debieran, me encuentro con un artículo en el que el demandado responde a las acusaciones: Wipro responds to National Grid’s SAP implementation billion dollar lawsuit

En el artículo se analiza cómo se desarrolló el proyecto y quienes fueron los actores implicados y al final se lanzan una serie de preguntas reveladoras:

  • ¿Dónde estaba EY? Eran los que llevaban la gestión del proyecto. Se supone que deberían tener un mínimo conocimiento de lo que se traían entre manos.
  • ¿Dónde estaba SAP? Como responsable del producto, debería supervisar mínimamente el correcto uso del mismo y las soluciones propuestas por el implantador.
  • ¿Dónde estaban los responsables del proyecto de National Grid? La última palabra siempre la tiene el cliente y es responsabilidad suya validar cada una de las fases del proyecto.
  • ¿Dónde estaban los auditores? En proyectos de cierta envergadura es más que aconsejable contar con la asesoría de alguien especializado y mejor antes de que ocurran los desastres, ¿no?

Y esto no se trata de buscar culpables, sino de asumir que un proyecto es responsabilidad de todos y que cuando algo falla, es muy probable que todos tengamos nuestra parte de culpa.

Recuerdo un proyecto de implementación en el que participé hace ya unos cuantos años en el que el responsable del proyecto por parte del implantador decidió salir a producción sin hacer una cantidad mínima de pruebas.

Por aquel entonces, yo debía tener 4-5 años de experiencia, y se me ocurrió sugerir que lo veía “un poco” arriesgado y su respuesta fue: “Nadie te ha pedido tu opinión y si quieres lo hablamos luego fuera”, en un tono no demasiado amable.

Lo dejé pasar y no entré al trapo de “hablarlo fuera”… aunque quienes sí tuvieron que esperar fuera, a los 2 días de esa conversación, fueron los camiones que iban a cargar mercancías porque, como no podía ser de otra forma, el sistema no funcionó. Bueno, para ser sincero, estuvo funcionando un par de horas.

Lo mejor fue luego, a la hora de buscar culpables (por supuesto, eso es lo primero que hay que hacer, antes de intentar arreglar las cosas…), se intentó justificar el desaguisado con que un programador había creado mal una tabla.

Evidentemente, ni la culpa fue del programador ni del que tomó esa “acertadísima” decisión, fue un poco culpa de todos, pero ya se sabe que eso de reconocer nuestras carencias, algunos no lo llevan demasiado bien.

Recuerdo que en más de una ocasión le dije al responsable: “Creo que no estamos capacitados para llevar a cabo un proyecto de este nivel”.

Y él me dijo: “¿Quién yo?”.

Y yo le respondí: “No, no lo decía concretamente por ti. Lo decía por todos, en general”.

Y su respuesta fue: “Habla por ti”.

Recordando esta historia, se me han ido viniendo otras a la cabeza, que iré publicando en los próximos días.

Como no hice la mili, alguna batallita tendré que contar cuando sea (más) mayor, ¿no? 😉

2 comentarios sobre “Trabajar como un equipo (I)

  1. La palabra “no” está muy mal vista y estigmatiazada en España. Parece que si dices “no” a algo se acaba el mundo y muchas veces ese “no” ahorra costes y tiempo al proyecto. A eso súmale que la soberbia es característica común en España y el “buscar culpables” el deporte nacional, así salen los proyectos al final…

    1. Totalmente de acuerdo, saber decir “no” es una habilidad fundamental en los tiempos que corren.

      Evidentemente, un “no” con sentido, no decir “no” a todo. Y estoy convencido que el cliente sabe valorarlo… y si no, quizás no debería ser tu cliente.

      Sobre lo otro, primero solucionemos el problema y después, más que buscar culpables, aprendamos para que no vuelva a pasar.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.