¿Acaso el PMP sólo vale para proyectos informáticos? ¡¡NO!!
La semana pasada, en una conversación con un amigo, ingeniero informático, surgió una cuestión a la que ya me he enfrentado en multitud de ocasiones: la identificación de la certificación PMP con la gestión de proyectos informáticos. Y, además, el recurso al PMP como excusa para trabajar mal.
Es incuestionable que abundan las personas certificadas como Project Management Professional provenientes del mundo de la informática, como es incuestionable que el número de proyectos informáticos que se desarrollan cada día es enorme (¡el software se está comiendo el mundo!). Sin embargo, esto no significa que la disciplina de la gestión de proyectos o las certificaciones del PMI sólo sirvan para los proyectos de desarrollo o integración de software. Sin ir más lejos, el PMI se fundó a finales de los años 60, alrededor de las prácticas de gestión de proyectos que comenzaban a generarse en la industria aerospacial y en la construcción, y que no tardaron en extenderse a otras áreas de la ingeniería.
El PMBoK es el corpus de conocimiento que recoge las mejores prácticas en gestión de proyectos recopiladas y “aceptadas” por el PMI, y es la base teórica de certificaciones como el PMP. Cualquiera que conozca el PMBoK sabe que, en él, no se menciona ni una sola vez un concepto que sea propio y exclusivo de los proyectos informáticos. Tanto es así, que el PMI edita una extensión del PMBoK dedicada específicamente al desarrollo de software, que ayuda a los jefes de proyecto a “traducir” el contenido del PMBoK a las especificidades de este tipo de proyectos, igual que también hay extensiones para la gestión de proyectos en organizaciones públicas y en la construcción.
El conocimiento recogido en el PMBoK y del que te examinas para alcanzar tu certificación PMP es de aplicación a cualquier tipo de proyectos, ya sea la construcción de un puente o la adecuación de un local para abrir una panadería, mandar una nave a Marte o implantar un CRM. De hecho, llevo mucho tiempo defendiendo que la aplicación de estas buenas prácticas de gestión de proyectos en las áreas de marketing ayudaría mucho a las empresas. Incluso tengo un primer borrador de un libro al respecto, pero esa es otra historia.
El PMP como excusa
Decía mi amigo que, en su empresa (dedicada a la comunicación digital), hay jefes de proyecto (ingenieros informáticos) que, incluso cuando todo apunta a que es una mala idea, se empeñan en que el cliente debe firmarles el análisis funcional para empezar a trabajar porque “así lo dice el PMP”. Vaya sarta de barbaridades.
El PMP no dice nada: el PMP es tu certificación. Si acaso, sería el PMBoK quien “dice” algo. Pero, ¿dónde se dice algo así? El PMBoK establece, por ejemplo, que se debe crear un acta de constitución del proyecto (Project Charter) y define ciertos inputs habituales para su creación, pero no menciona, en ningún momento, que exista la obligación de hacer un análisis funcional. Ni siquiera la extensión para proyectos de software establece tal cosa. Lo que sí dice el PMBoK es que la organización y/o el jefe de proyecto son los responsables de determinar qué es lo correcto para cada proyecto y situación. Hay flexibilidad. Hay que pensar. La RFP, la propuesta y el contrato pueden ser material más que suficiente para alcanzar el consenso inicial y comenzar el proyecto.
Y, si no son suficientes, adelante, compleméntalos. Si crees que el cliente te debe firmar un análisis funcional para empezar a trabajar, arguméntalo, defiéndelo y demuestra los beneficios para el negocio. No recurras a “lo dice el PMP”, porque no es cierto. Es un argumento doblemente falaz. Además, tu responsabilidad como jefe de proyecto no es seguir al pie de la letra estándar alguno, sino asegurar el éxito del proyecto y, para eso, es fundamental adaptarse a la situación concreta: si, en un proyecto de comunicación digital, el cliente (que no es un interlocutor tecnológico) puede verse desorientado por un análisis funcional, quizá no sea la mejor manera de consensuar el alcance, ¿no? Si el alcance no está claro al principio, que es lo normal, y te da miedo empezar el proyecto en esas condiciones, ¿has pensado en adoptar, por ejemplo, un enfoque ágil? El contenido del PMBoK sirve para gestionar proyectos de comunicación digital, si tienes la perspicacia y la flexibilidad necesarias para aplicarlo.
Por cierto, para terminar de hacer sangre: algo de lo que sí habla mucho el PMBoK es de Earned Value Management. Los que dicen que “esto debe hacerse así porque lo dice el PMP”, ¿aplican Earned Value Management en sus proyectos? Déjame apostar.
