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 hacerlos), que un blog es una conversación desnuda, directa y sin filtros ni censuras. A lo mejor, por eso me gusta el formato, aparte mi abulia para escribir o investigar cosas muy largas o publicar papers. De manera que me he animado a escribir una pieza un poco más personal: cómo aprendí a hacer proyectos y qué fui aprendiendo con el tiempo.

No soy un estupendo director de proyecto (de hecho no soy un estupendo nada).  Tiendo a ser un poco caótico, creativo y contradictorio. Hay cosas que olvido y otras que no planifico. De eso he aprendido varias cosas: que siempre se te olvida algo, que no todo es planificable y que es bueno tener en el equipo un jefe de proyecto mejor que yo.

Empecé trabajando en compañías de consultoría estratégica. En mi curso de iniciación había un círculo con fases, que no recuerdo, y en el centro del círculo estaba la comunicación. La entrevista, el informe, la reunión formal e informal con los clientes y los equipos era el núcleo del proceso.  El informe y las presentaciones eran el producto. Los consultores éramos escritores y oradores profesionales, decía mi jefe.

Aprendí también a preguntarme por los problemas que el cliente quería resolver (los issues o temas clave), más que a pensar en mi producto. Mi producto era resolver los problemas del cliente (cómo ganar más dinero, ahorrar costes o vivir mejor), o ayudarle a resolverlos. A veces eso no tenía que ver con el encargo. Aprendí a decírselo. Aprendí la importancia del diagnóstico (qué pasa aquí, qué nos está pasando en realidad) y la desconfianza (dudar de lo que te cuentan).

Todavía hoy pienso que los proyectos se deben gestionar desde los objetivos y los contenidos (qué quiere el cliente y cómo mi proyecto le puede ayudar) y no desde las tareas y las actividades. Alguien le llamó a eso Issue-Driven Project Management (2). Aprendí a llevar un registro de open issues (o sea los temas antiguos o sobrevenidos que aún no hemos resuelto), que me sigue pareciendo una de las herramientas de gestión de proyectos realmente útil.

Nunca hablábamos mucho con los usuarios, no solía ser un issue, y más frecuentemente era un engorro y una desviación del camino principal. Todavía ahora, en proyectos de BI (Business Intelligence) a los que me dedico mucho,  hacemos mapas estratégicos antes de hablar con los usuarios, quizá como mucho una entrevista corta con un directivo o usuario clave.  Las reuniones, el proceso y los resultados son más rápidos y mejores.

No es prepotencia, de hecho es humildad. El cliente sabe más que tú de su negocio, pero no tiene tiempo o concentración o capacidades para gestionar un proyecto. Te llama para que le salves, eres un mal necesario. Es asumir riesgos, responsablemente. Y si lo haces mal, si te equivocas, debes avisar a tiempo, disculparte y corregirlo.

Más tarde, ya en la informática o con la informática, aprendí de un enfoque que se llamaba Goal-Directed Project Management (GDPM), del que todavía se vende un libro de unos tipos noruegos y se visita una web (3). Mi compañía lo había adoptado como estándar de trabajo en todo el mundo. La planificación y gestión de los proyectos se hacía top-down: los objetivos de cliente y de proyecto se cruzaban para asegurar su consistencia, cada objetivo se descomponía en hitos y entregables y se establecían roles y responsabilidades sobre cada producto en equipos de proyecto compartidos entre el cliente y el implantador. Eran proyectos mixtos, “mestizos”, con una parte de informática y otra parte de organización, procesos y personas. La comunicación y la gestión de la “política” (los famosos stakeholders) dentro del proyecto y sin complejos eran clave. Eso se llamó después gestión del cambio. Lo hemos explicado en un libro editado por la editorial de la UOC (4).

Como hay más batallitas, las dejo para una segunda entrega.

Notas

1. Scoble R, Israel S (2006). Naked Conversations: How Blogs are Changing the Way Businesses Talk with Customers (Wiley)

2. Ver, por ejemplo, Rasiel E. (1999). The McKinsey Way (McGraw Hill)

3. Andersen E, Grude K, Haug T. (2009). Goal Directed Project Management: Effective Techniques and Strategies (Kogan Page). Ver también la web www.gdpm.com

4. Rodríguez JR, Lamarca I, García Mínguez J. (2007). Gestión de Proyectos Informáticos: métodos, herramientas y casos (Editorial UOC)

Comentar

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

Leer entrada anterior
Esta máquina es un Enigma “RNGNTETKWBBRVQJQPDBFN”

Durante la Segunda Guerra Mundial, los alemanes utilizaron en sus comunicaciones secretas una máquina, la “Enigma”, que pensaron era indescifrable....

Cerrar