Cómo aprendí a gestionar proyectos (II)

Sigo de un post anterior (Cómo aprendí a gestionar proyectos (I)).

Cuando comenzó la era de los ERPs y otros sistemas de información de empresa, aprendí que dedicar mucho tiempo a tomar y analizar la situación actual y los requerimientos de usuario (as is) no era muy práctico, y que valía más la pena llevar lo antes posible prototipos basados en cómo será la aplicación futura (to be), que cubriesen el grueso de la funcionalidad y estuviesen basados en el estándar. Esto permitía apuntalar el liderazgo del cliente y del equipo frente a las presiones del usuario final y, al revés, escuchar pronto y cambiar sin mucho coste las peticiones de usuario que tenían sentido, y encajarlas lo más posible en el estándar. Thomas Davenport lo explica mucho mejor que yo en un libro que es ya clásico (1). Dice Davenport que adoptar un ERP es un “estilo de vida”. Hacer proyectos de ERP también.

Aprendí con los años que gestionar proyectos era sobre todo arremangarse, estar al pie del cañón y con las antenas desplegadas y cuidar de un equipo (el tuyo y el del cliente) confiable, sensato y enfocado a la ejecución. Dice Larry Bossidy, exdirectivo de General Electric y autor de uno de los mejores libros de management de la última década: “Los que ejecutan te salvarán la vida” (2). Yo escribí hace tiempo: “El que escribió la metodología no estaba en el cliente”.

Cuando empecé a hacer webs, intranets, plataformas de comercio electrónico y a trabajar con nuevos medios y canales, descubrí gente que no conocía y de la que aprendí mucho: diseñadores, librerías de código abierto, miles de aplicaciones disponibles en la red y gente dispuesta a ayudar, compartir o competir. Descubrí que la construcción de software no era un paseo militar, sino que podía ser una disciplina un poco artística e iterativa, si se mantenía un mínimo vocabulario y algunas reglas comunes. Descubrí que se podían hacer cosas más ágiles sin tantas prisas, en un proceso donde la comunicación, los prototipos, las versiones beta, la pura innovación eran más posibles, más ubicuas y más baratas. Aprendí a tener paciencia y a confiar y comunicar que aquello que hacían esos tipos saldría bien, saldría a tiempo y saldría barato. A veces me equivocaba, pero no más que haciendo las otras cosas de las otras maneras.

(He prometido alguna vez hablar de Agile y otras hierbas.  ¿Es Agile un enfoque de ingeniería del software, una aproximación diferente de hacer proyectos,  una nueva religión o también un estilo de vida? ¿En cuál de nuestras imaginativas clasificaciones del conocimiento encaja Agile? Lo seguiré pensando.)

Un día escribí que alguien debía inventar y sentir una aventura, una leyenda, una historia en cada proyecto que dirigía o en que participaba. Tom Peters, el gurú del management, decía más: “Cualquier actividad puede convertirse en un proyecto asombroso” (3).

Me llaman clientes o a veces compañías de servicios, inmersos en proyectos que se han convertido en enormes “marrones” y que les costarán el puesto o la empresa. Qué pena. Me llaman para arreglarlo y lo pagan bien.

Casi siempre suele ser la misma cosa: unos y otros comunicaron poco y mal, los objetivos del proyecto se perdieron por el camino, el cliente no hizo lo que debía, el consultor no supo o no se atrevió a avisar o decir la verdad en beneficio del cliente, el jefe de proyecto estaba contando las horas, escribía informes de seguimiento imaginarios o  estaba tomando cañas, el proyecto era largo y nadie veía resultados ni valor durante mucho tiempo, se hizo demasiado caso a usuarios que no querían cambiar su manera de trabajar o no sabían lo que querían, nadie mandaba nada, el diálogo se había roto hace tiempo y nadie se fiaba de nadie.

Estos clientes y proyectos “enmarronados” se parecen a un matrimonio. Yo suelo intentar que las cosas no lleguen a los tribunales y que los matrimonios no se rompan. El matrimonio se acaba un día y hasta se puede arreglar a veces; pero el divorcio, en la informática y en la vida, dura toda la vida y no tiene remedio.

Notas

1. Davenport T. (2000). Mission critical: Realizing the promise of Enterprise Systems (Harvard Business Press).

2. Bossidy L, Charan R. (2002). Execution: The Discipline of Getting Things Done (Crown Business)

3. Peters T (1999). The Project 50: 50 ways to transform every task in a project that matters (Excel  California Partnership).

2 Comments

  1. Muchas gracias por poner por escrito lo que muchos de nosostros pensamos. Cuando los proyectos no son gestionados semana a semana, finalmente hay un divorcio entre provedor y cliente, y llegar a un mutuo acuerdo es ya casi imposible.

    Reply
  2. Hola.

    Después de trabajar catorce años en diferentes consultoras de IT, lo que ha llegado es mi divorcio personal con esta profesión y ahora me dedico a algo completamente diferente y feliz que estoy. Para m el resumen es la falta de profesionalidad y la merienda de negros en la que se ha convertido la consultaría informática … ¡¡Hasta nunca!!

    Reply

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Leer entrada anterior
Cómo aprendí a gestionar proyectos (I)

Dicen Scoble e Israel (1), autores de uno de los más famosos y atractivos libros sobre blogs (y sobre cómo...

Cerrar