¿Por qué PMBOK no es una metodología?

La discusión y las preguntas, en internet, son constantes y casi siempre se centran en comparar los méritos de la metodología PRINCE2 con la “metodología” PMBOK. Sin embargo, no podemos ni debemos aceptar como costumbre algo que está mal. Nunca, bajo ningún pretexto. Y el problema de la idea que se menciona más arriba es que su premisa básica es por completo errónea. No hay vuelta de hoja ni medias tintas; pensar así es incorrecto porque el argumento está mal. La Guía Project Management Body of Knowledge (PMBOK) no es y nunca ha sido una metodología. No fue concebida como tal.

¿Por qué?

Pues ver la diferencia es sencillo en realidad. Todas las metodologías definen los procesos, responsabilidades y flujos de trabajo necesarios para lograr un objetivo. PRINCE2 es una excelente metodología para la gestión de proyectos que tienen un componente interno muy vasto —pensemos en estructuras de gobierno o grandes organizaciones. Mientras que Agile y Waterfall son dos metodologías de desarrollo de software muy distintas entre sí, pero que incorporan elementos de dirección de proyectos.

PMBOK es un estándar de la American National Standards Institute (ANSI). En este ambiente profesional tan lleno de siglas y acrónimos, no nos cansamos de hacer referencia al nombre completo en inglés de nuestro bien conocido tomo de la PMBOK: A Guide to the Project Management Body of Knowledge. Sí, de entrada lo más correcto gramaticalmente, sería referirnos al libro de texto como la PMBOK, porque es una guía. Luego, tenemos que tomar muy en cuenta que los procesos descritos en la PMBOK son buenas prácticas generalmente aceptadas que aplican a la mayoría de los proyectos, la mayor parte del tiempo.

Esto por sí solo, podría ser el fundamento perfecto para la creación de una metodología bastante sólida destinada a aplicarse a la dirección de proyectos... pero existe un detalle pequeño —y quizá por eso sucede que muchas personas parecen pasarlo por alto— pero de vital importancia: la guía PMBOK no es  y nunca podrá ser una metodología, si antes no realizamos varias adaptaciones específicas.

La brecha real que existe entre la guía PMBOK y una metodología en forma, se encuentra en la parte correspondiente a la determinación de qué se debería hacer por quién, cuándo tendría que hacerse y cómose debe realizar, cosas que como rutina nos planteamos de la siguiente manera:

• ¿Qué procesos deberían ser utilizados —en la organización cliente o bien la nuestra—, hasta qué punto y con cuánto rigor?
• ¿Quién es el responsable de la implementación de los procesos, incluyendo los roles y responsabilidades generales, las estructuras de organización del proyecto y los comités de gobierno?
• ¿Cómo serán aplicados los procesos? Se generarán plantillas, guías y flujos de trabajo, sí, ¿pero éstas tendrán diferentes niveles de profundidad o distintos enfoques? ¿Se trabajará con criterios homologables, generales o estrictos?

Estos puntos representan temas de relevancia crítica.

• Si una PMO se dedica a la tarea de ‘implementar el PMBOK’,  es muy probable que nos encontremos en rumbo directo y con muy pocas escalas hacia un desastre.
• Si la misma PMO se da a la tarea de desarrollar una metodología personalizada, que esté fundamentada en las buenas prácticas que se describen en la PMBOK, entonces es muy probable que vayamos por el camino adecuado.

A lo largo de mi experiencia laboral en proyectos de comunicación de distintos tamaños, me he encontrado con varias personas que no saben bien cuál es la diferencia entre lo que es un estándar y una metodología. Por supuesto es sólo un ejemplo, pero aplica para cualquier proyecto sin problemas y, el hecho de que suceda, dificulta la etapa de planificación así que lo que más se recomienda —otra vez mis padres y un terapeuta tienen que llevarse el crédito por esto— es hacer muchas más preguntas acerca de las percepciones, los objetivos y el alcance, en lugar de ponernos a cuestionar el grado de competencia de nuestros interlocutores. No podemos darnos el lujo de generar conflictos innecesarios, de hecho estamos para evitarlos o solucionarlos antes de que se desborden. A través de nuestros cuestionamientos, podemos detectar donde están las fallas de apreciación o las confusiones y entonces podemos comenzar a explicar las diferencias y, así, corregimos errores sobre lo que las personas perciben acerca de la guía PMBOK, la cual no podemos negar que es un recurso muy valioso para controlar y supervisar el desarrollo de cualquier metodología de dirección de proyectos que necesitaremos para el caso específico que estemos atendiendo. Pero ya con las aclaraciones hechas y encontrándonos todos en sintonía, de todas formas necesitaremos realizar la tarea de determinar todos los qué, quiénes, cuándo, cómo y cuánto o qué tanto.

Porque también es de mucha importancia reconocer y aceptar que existen huecos en la PMBOK, que tendremos que llenar nosotros con la información que sea necesario desarrollar e incorporar en nuestra metodología específica para el caso que nos ocupa. Suena un tanto preocupante hablar de “huecos” —además de que son justo éstos los que hace que la PMBOK no sea una metodología en forma—, pero no hay motivos para entrar en pánico ya que éstos están perfectamente identificados:

1. Tenemos que saber con exactitud qué es lo que vamos a hacer. Esto, obviamente, cambia de proyecto a proyecto. La PMBOK sólo nos ofrece una guía general y dice esto muy claramente.
2. Tendremos que definir con precisión las entradas, salidas y los criterios de desempeño. La PMBOK casi no menciona estos puntos y, si lo hace, en realidad se trata de abstracciones o conceptos teóricos. Si hablamos del análisis cualitativo de riesgos —tan en boga en esta época de crisis mundial—, la PMBOK tiene muy claros los impactos relativos… Pero para nuestro proyecto en turno, ¿qué implica en realidad un impacto de 0.80 (extremo) en términos cuantitativos? ¿Cuánto nos va a costar? ¿Qué recursos no serán bien aprovechados al estar mal asignados o cuáles se verán limitados por esto? ¿Quién tendrá que estar más atento a las señales de alerta y cuáles y cómo se determinarán éstas? La metodología del proyecto tiene que definir de manera muy clara todos estos puntos. Sobre todo porque el ‘impacto’ aplica a la calidad, la seguridad, el tiempo o los costos: ¿cuáles de estos son relevantes y necesitan ser incluidos en la metodología? ¿Cuáles podemos dejar fuera sin mayores preocupaciones? Obvio, esto sólo lo podemos determinar conociendo muy bien el alcance y el tamaño del proyecto en el que estamos involucrados y las instrucciones precisas de las partes interesadas y los patrocinadores.
3. Hemos de definir qué personas serán responsables de realizar cuáles tareas, por medio de roles específicos. La PMBOK, una vez más, sólo ofrece información general en tanto que una metodología en forma define de manera muy precisa cuáles son los roles, responsabilidades y niveles de autoridad.
4. En cada caso, tendremos que desarrollar plantillas que sean fáciles de utilizar para los usuarios que las requieran, así como documentación con los lineamientos para que los procesos se implementen de manera consistente. La PMBOK casi no las menciona.
5. Hay que definir los flujos de trabajo. La PMBOK es bastante explícita en tema, pero únicamente en lo tocante a una sola corrida; las metodologías necesitan lidiar con construcciones o desarrollos iterativos.
6. Por último, llegamos a la cuestión de que tan a menudo deben utilizarse los procesos, con qué intensidad deben aplicarse, quién supervisará los procesos, cómo se medirá el desempeño, cómo se mejoran nuestros procesos  y qué sucede si existe un problema o alguna situación identificados previamente.

Lo anterior, es una descripción básica de lo que debe contener una metodología de negocio que esté bien diseñada; por lo tanto, es consistente y compatible con los conceptos empleado por la Six Sigma, está tan bien definida dentro de un enfoque apegado a la metodología  PRINCE2 y se le puede valorar —hasta cierto punto— por medio de los parámetros de la Estructura OPM3 creada por el PMI.

Como podemos ver, todo lo que ofrece la guía PMBOK es precisamente los que dice que ofrece: “un conjunto de buenas prácticas generalmente aceptadas que pueden utilizarse en la mayoría de los proyectos la mayor parte del tiempo”. Nada más. Una metodología construirá sobre este comienzo definiendo   qué, cómo, quién, cuándo y con qué frecuencia. Si no lo hace, no es una metodología porque no resuelve los principios básicos con los que se determinan las acciones necesarias para llevar a cabo un proyecto. Incluso los autores responsables de la creación de PRINCE2 esperan que las organizaciones adapten de maneras constructivas su propuesta de metodología para que ésta se ajuste a sus necesidades: ¡no es una panacea!  Es virtualmente imposible que se ajuste de manera precisa a todos los casos. Se necesita de mucho trabajo duro para lograrlo, no hay recetas mágicas.

No se puede negar que la PMBOK es un excelente punto de partida —como también lo es PRINCE2—, y todos sabemos que tener buenos cimientos es una cuestión de máxima importancia, pero los cimientos sólo son el punto de partida… apenas el comienzo del esfuerzo. Una vez que las bases sean las adecuadas y estén hechas de la manera correcta, comienza el verdadero trabajo que implica la construcción de una metodología útil —o bien el de adaptar una ya publicada. La verdadera habilidad que tengamos quedará evidenciada cuando nos aseguremos de que la metodología sea tan simple, rápida y fácil de usar como sea posible y, al mismo tiempo, aplique el rigor suficiente para que se puedan optimizar los resultados de nuestros proyectos.

Espero que esto ayude a despejar las posibles dudas y elimine la confusión de términos para que podamos concentrarnos en la esencia de la profesión: llevar la dirección de nuestros proyectos por la mejor senda posible y hacia una terminación exitosa.

Fuente: www.liderdeproyecto.com