¿Por qué hace falta un curso de Project?

Hace unos años hice un descubrimiento: Me tomé de vacaciones la semana de Semana Santa y alguien me había prestado un libro cuyo título era algo así como “aprenda Microsoft Project paso a paso”. Me dediqué concienzudamente a estudiarlo, hice todos los ejercicios, y así acabé entendiendo cómo funcionaba esta herramienta. Cuando volví a mi trabajo pude comprobar que me hacía ganar mucho tiempo, fundamentalmente a la hora de controlar mis proyectos, pero también a la hora de hacer propuestas de servicios profesionales (que para mí no son otra cosa que la “versión cero” de un plan de proyecto).

Yo por aquel entonces dirigía un grupo de consultores, como el negocio no iba bien teníamos que responder a todas las peticiones de propuestas que pudiéramos. Había algunas semanas que teníamos que generar 2 y hasta 3 propuestas de servicios de consultoría. Mi frustración permanente tenía que ver con el tiempo que perdíamos con las herramientas ofimáticas.


Nuestro producto final era un fichero en PowerPoint (se entregaba una versión en PDF), pero para llegar a él había que representar el alcance y el flujo de los trabajos, había que explicar los detalles de cada trabajo, había que justificar muy bien cuántas horas se consumían y nuestra base para las estimaciones, los riesgos, etc.

En definitiva, había que “armar” muy bien la propuesta porque el cliente luego querría reducir el coste, y la única defensa sería que reducir coste conlleva reducir alcance y esfuerzo. Todo ese montaje era muy necesario, pero perdíamos tanto tiempo con la ofimática, que cuando había que ponerse a escribir sobre nuestra propuesta de valor, nuestro enfoque diferencial, o por qué nosotros, etc., generalmente estábamos tan agotados y quedaba tan poco tiempo, que el resultado no era bueno.

Después de aquella experiencia autodidacta sobre Project, acabé aplicándome “mi propia metodología” para hacer propuestas en 2 días, y también intentaba que mi grupo la siguiera. Mi procedimiento era más o menos el siguiente:

• Una vez comprendida la necesidad del cliente, que generalmente se detallaba en un pliego de prescripciones técnicas, lo primero que hacía era abrir un fichero de Microsoft Project que ya tenía inicializados los días festivos. En una tarde generaba un Gantt con las actividades y los plazos que yo pensaba que podían defender y explicar nuestra propuesta. Aprovechaba el campo “notas de la tarea” para describir la información de detalle que se me ocurría en ese momento.
• Si había que debatir el enfoque de solución dentro de mi empresa, el fichero Project generalmente era suficiente para comunicar y solicitar el juicio de expertos.
• La propuesta económica comenzaba siendo un Excel de alto nivel, con las grandes partidas de coste: honorarios, materiales, gastos, reservas, etc. Cuando tenía la aprobación del presupuesto por parte de mis superiores, lo siguiente era “cuadrar” los honorarios en Project. Asignando recursos a las actividades, y editando el uso de los recursos a lo largo del tiempo, lograba cuadrar sin mucho esfuerzo las horas totales.
• A partir de entonces el trabajo ya era más o menos mecánico: Alguien podía encargarse de generar el WBS a partir del Gantt. Luego preparaba un “esqueleto” en PowerPoint, dejando huecos para describir las partes del alcance, del calendario, los hitos, las actividades, etc. Los expertos entraban directamente la información de valor: no perdían tiempo con la ofimática.

Que la información estuviera centralizada en Project nos permitía también sistematizar la producción de cierta información muy útil para defender la propuesta, como es la carga de trabajos por perfil y tarea, la distribución temporal (por semana, por mes, por trimestre, por año) de los trabajos, de los costes, etc., por grupo de recursos, por grupo de trabajos, por departamentos dentro de la organización, etc. Podíamos adaptarnos a la necesidad de análisis que tuvieran nuestros clientes sin “enredarnos con el Excel”, simplemente había que utilizar las vistas de Project ya pre-existentes.

Project también tenía un efecto sobre la imagen comercial que transmitíamos. Indirectamente, una propuesta armada con Project “vendía” nuestra profesionalidad como Project Managers. Desde la fase de propuesta, los clientes ya tenían una impresión sobre el plan de proyecto y el rigor que se iba a utilizar durante su control y seguimiento.

En nuestra comunidad de Project Managers, Microsoft Project se considera un estándar de facto. En las entrevistas de trabajo se nos pregunta si dominamos esta herramienta. Nos parece tan básica para nuestro día a día como el Excel puede parecerle a un contable.

Sin embargo, mi experiencia es que muchos Project Managers, como me pasaba a mí mismo, creen que saben usar Project, pero no saben que no saben. Utilizar Project para pintar cronogramas es sin duda mejor que usar otras herramientas, pero pocos se atreven a planificar los recursos, y muy pocos utilizan las vistas de seguimiento para explicitar las desviaciones temporales y de coste. Queremos tener el Project instalado, pero cuando nos decidimos a usarlo para otra cosa que no sea pintar gantts, generalmente nos produce mucha frustración. Como Project viene incluido en el paquete de Microsoft Office, tendemos a pensar que se aprende igual de Microsoft Word. Ojalá fuera tan fácil.

Para aprender Project hay que estudiarse muy bien un libro como aquél que yo utilicé aquella Semana Santa, o bien hay que tomar un curso de tipo práctico, que nos dé las claves que necesitamos para planificar y controlar nuestros proyectos.


Este post es una transcripción de un artículo que escribi para el curso online de Project Management de IEDGE. Pueden ver otros artículos míos generados para IEDGE pulsando aquí.