Es gracias a -entre otros- estándares como el PMBOK (Project Management Body of Knowledge) del PMI (Project Management Institute) que se ha conseguido unificar conceptos, criterios y prácticas y, lo más importante, homogeneizar y hasta homoolgar el lenguaje de la gestión de proyectos.
Sin embargo, los estándares se aplican y viven como prescriptivos, es decir, “esto se hace así”. Revisando el origen de estándares como el PMBOK, en su origen y esencia las cosas no son así ni se pensaron así. Se buscaba flexibilidad. Pero los estándares han sido culpables de su formalidad.
Se volvieron “tan” formales, que se volvieron extensos, “cansinos”, engorrosos, y en manos de personas con poca experiencia o muchos/muchas “vende humo” les usaron para escudarse en la aplicación estricta de estos estándares para ocultar falencias de experiencia, conocimiento y práctica en gestión de proyectos.
Lo bueno es que la versión 7 del PMBOK, del 2020, hizo algo muy singular. Dejó de plantearse el estándar como algo prescriptivo o quizo evitar que se le usase como tal. Lo hizo orientativo.
El PMBOK versión 7 dejó de lado que las cosas se interpretaran como “aquí se aplica ésto” a “piensa lo que quieres conseguir y escoge con criterios claros lo que debes aplicar, y aquí te sugiero algunas cosas que te servirán, pero si necesitas algo más o crees que otra cosa sea más útil, pues usa lo que sirva”.
Personalmente lo veo más aplicable a project managers experimentados. De hecho aporta versatilidad, flexibilidad, escalabilidad, orientación, agilidad, fluidez, y mucha frescura.
Pero esta nueva forma de enfrentar la actividad profesional del gestor o gestora de proyectos puede sentirse poco práctica. Pero esto se debe a que muchas veces se “leen” los estándares como un libro que debe dar respuesta concretas y específicas. Y muchas personas usan los estándares para esto, para decir “lo dice el estándar” o “el estándar no lo pone”.
Por lo mismo, si ahora el PMBOK versión 7, dice, te dice “te sugiero, o lo dejo a tu criterio, o aquí te muestro cosas y tú estudia si te sirven estas cosas u otras”, incomoda. Por ello es relevante analizar esta nueva versión, , DEJANDO CLARO que el PMBOK versión 6 sigue existiendo y aplicándose, no ha sido reemplazado.
Bueno, más allá de estas reflexiones de practitioner, debemos ver ahora cómo opera el PMBOK versión 7.
A continuación presento el PMBOK versión 7 como un framework analizando cada uno de los elementos que aporta.
El paso del PMBOK versión 6 a versión 7.
Sin embargo, existen otros estándares prestigiosos, pero el alcance y masificación del PMBOK es mayor. El PMBOK es un libro, una guía, y su contenido expone una metodología de “cómo hacer” una correcta y completa gestión de proyectos.
El PMBOK hasta la versión 6 (vigente aún) presentaba y se organizaba alrededor de la PMBOK Guide, que en suma es una descripción pormenorizada de los procesos de gestión de proyectos, que es cómo el PMI organizó el conocimiento mundial de gestión de proyectos.
Cada proceso se vincula, por un lado, a un área de conocimiento y, por otro lado, a una fase o etapa del ciclo de vida de un proyecto: (a) las áreas de conocimiento especifican el conocimiento que se debe manejar en un proyecto; y, (b) el ciclo de vida se compone de cinco (5) fases (Inicio o Iniciación, Planificación, Ejecución, Monitoreo y Control, y Cierre) que como mínimo cada proyecto debe aplicar siempre. Así, cada proceso pertenece a una única área de conocimiento y se ejecuta en una única etapa del ciclo de vida.
Tanto áreas de conocimiento como fases del ciclo de vida, son aspectos, elementos y/o momentos que todo Project Manager no debe descuidar en su actividad profesional al gestionar un proyecto. •El PMBOK Guide es una “matriz” donde los procesos se muestran organizados por áreas de conocimiento (filas) y fases o etapas del ciclo de vida (columnas).
En el 2020 se libera la versión 7 del PMBOK. En esta versión el PMBOK es un libro y una base de datos online (PMIStandards) con material de casos, templates, etc., la que se actualiza continuamente.
En la versión 7, el PMBOK simplemente añade “alrededor” del PMBOK Guide varios elementos que definen o marcan el enfoque o postura con que un Project Manager debe asumir un proyecto.
Por ejemplo, estar siempre dispuesto a adaptar su forma de pensamiento y de trabajo, o actitudes ante su desempeño y el desempeño de la gestión del proyecto ante contextos de gobernanza organizacional que engloban a un proyecto.
Esto forma de presentación u organización aporta flexibilidad y riqueza a un Project Manager en su actividad profesional, pues el PMBOK ahora le orienta aportándole una estrategia de gestión para la gestión del proyecto.
En este momento, la versión 6 y la versión 7, están vigentes. Antes una versión reemplazaba a la previa, ahora –o lo más razonable- es que coexistan y se completen mutuamente.
Para el Project Manager, la versión 7 es un marco de trabajo y la versión 6 el instrumento a aplicar.
Los Principios de la Dirección de Proyectos.
La idea de enfatizar “unos principios” es para dar un marco de principios al Project Manager y que no realice su actividad profesional “a su estilo” o “interpretación”.
Los principios en esencia marcan o proveen un sustrato esencial en un profesional de la gestión de proyectos. Pero más que eso, “manda una señal” de que un profesional de la gestión de proyectos debe realizar su actividad profesional con principios profesionales “universales” que no reemplazan códigos éticos o deontológicos u otros que tenga el Project Manager, su profesión, y/o el contexto donde se desenvuelve.
Así, el PMI presenta principios esenciales, que pueden ampliarse. Pero no disminuir o reducir o eliminar alguno.
Ahora el Project Manager, haga lo que haga, lo hará dentro de principios profesionales y universales.
Los Dominios de Desempeño del Proyecto.
No se presentan ni describen actividades, sino más bien se da a entender “que existen”. Pero si se aclara que estas actividades se relacionan entre sí y son fundamentales para la entrega efectiva de los resultados del proyecto. Y se sigue diciendo que son áreas de énfasis interactivas, interrelacionadas, e interdependientes que funcionan al unísono para conseguir los resultados del proyecto.
En suma, los dominios de desempeño constituyen indicaciones de ”todo” lo que un Project Manager debe estar “pendiente” en cualquier momento del proyecto, no importa ni el área de conocimiento ni la tapa o fase del ciclo de vida.
Su presencia establece prioridades que un Project manager debe tener en mente SIEMPRE, sin importar cual metodología o enfoque de proyectos apliqué, esté aplicando o aplicará.
Ahora el Project Manager, haga lo que haga, lo hará preocupado de cuestiones esenciales presentes en cualquier proyecto.
Entorno y Valor.
Primero. El Entorno.
Se da énfasis al análisis del entorno, es decir, el contexto en el cual se desenvolverá el proyecto y el Project Manager.Se distingue el Entorno Externo y el Entorno Interno.
Básicamente, en una primera lectura, se habla –respectivamente– del entorno ”fuera de la organización” donde se desenvolverá el proyecto, y el “entorno organizacional” de la organización donde se desenvolverá el proyecto.
Pero en una segunda lectura, más general y amplia, y bajo una visión sistémica, se alude a un Entorno Externo que afecta al proyecto, pero sobre el cual puede que no exista control (llamado en systems thinking, el entorno mediato), y un Entorno Interno que afecta al proyecto, pero se tiene cierto grado de control (llamado en systems thinking, el entorno inmediato),
Ahora el Project Manager observa el entorno en función del impacto que tengan los agentes “alrededor” del proyecto, y cómo actúan sobre el mismo proyecto, no como antes, que era una visión más simple.
Segundo. El sistema de creación de valor.
Y se da énfasis a la creación del valor.Un proyecto y la gestión del proyecto son creadores de valor. Simple y directo. En realidad, puede considerarse una “obviedad”, pues nadie hacía ni hará proyectos que no aporten valor. Pero el énfasis es importante.
Si bien se aclara y se da relevancia a lo que se llama el sistema de creación de valor, no se detalla y es bueno destacar qué tipo de valor hay que preocuparse, ni de si es uno o varios valores que deben gestionarse.Esto ocurre porque según los actores del entorno y los del propio equipo del proyecto existen y co-existirán. Por ende, el valor puede ser multidimensional, podrá variar y diferirá según el poder de quienes son parte intrínseca del proyecto (equipo del proyecto) y extrínsecos al proyecto (la organización, sus directivos y otras áreas organizacionales, y lo que aporte el propio entorno externo e interno).
Pero esta omisión no afecta el mensaje el Project Manager debe preocuparse del valor, y en el sistema de creación de valor, es dónde el Project Manager tiene la mayor relevancia y presencia. De hecho es clave en la creación de valor..
Ahora el Project Manager, no debe percibirse como un ente aislado o alguien que debe cumplir “ciegamente” una misión, sino que hay un contexto y una finalidad: crear valor, no se es un “mero ente reactivo sino proactivo”.
Enfoque y Herramientas.
Primero. Enfoque – la adaptación.
El llamado Efoque es el enfoque con el cual el Project Manager asumirá su actividad profesional. No es el enfoque de un proyecto particular.Si bien lo que dice el PMBOK podría tener muchas interpretaciones, básicamente es el paradigma, epistemología o visión sobre cómo el Project Manager mira su actividad profesional y cómo asume la gestión del proyecto y el proyecto. Y esto es importante, porque podría decirse aquí que al Project Manager se le recuerda que debe equilibrar la Gestión del Proyecto con la consecución de resultado de ejecutar un Proyecto, y no pensar que construir un producto o resultado o entregable es su única misión, sino que además debe gestionar el proyecto.
El PMBOK es claro, “se debe ser adaptativo”.
La adaptabilidad es la esencia de la actividad profesional. Por contrapartida, cosa que no profundiza o más bien evita el PMBOK, es el enfoque opuesto, que sería el basado en que todo proyecto es así o “así lo he hecho siempre.” No hay crítica al cómo se hace actualmente, solamente declara que el Project Manager debe tener un enfoque y saber que puede haber varios enfoques.
No impone el PMBOK a tener una actitud profesional adaptativa, sino más bien abierta.
Ahora el Project Manager usa un enfoque de ADAPTACIÓN como una perspectiva para tomar una decisión, y no como un fin, o, haga lo que haga, debe ser adaptativo o al menos cuestionarse cómo mira los proyectos y debe pensar si su experiencia pasada es aplicable, o no,
Segundo. Herramientas.
Las Herramientas –término genérico– comprende todo el instrumental que el Project manager debe aplicar. Y es un instrumental a su vez clasificado en Modelos, Métodos y Artefactos, y para cada una de estas agrupaciones se sugieren muchas, bastantes, herramientas.Para entender la importancia de esta idea hay que “mirar” la PMBOK Guide de la versión 6, donde se presentan los procesos, cada uno, sí, uno a uno, en función de tres cosas:
entradas o inputs que necesita;
salidas, outputs o entregables que debe generar; y,
descripción de lo que debe emplear y de las herramientas a aplicar.
En la versión 6 se detalla cada input, cada output y cada herramienta, una a una, aunque se repitan algunas entre procesos.
Esto hizo, se aclara, que la versión 6 se considerase “bastante” impositiva en entradas, salidas y herramientas, aunque en realidad, se limitaba a aportar una base mínima y muy detallada de conocimiento para entender y aplicar y ejecutar cada proceso.
La versión 7 libera esta imposición (que –se insiste– es más bien un “mito urbano” o una “creencia popular”) y como no habla ni presenta procesos (“salva” la situación diciendo que hay ámbitos de desempeño que son grupos actividades –por ejemplo, procesos del PMBOK Guide o lo que se esté empleando para gestionar un proyecto, como PRINCE2 o PM2 o cualquier otro–) obviamente ya no hay herramientas “dentro” de procesos, sino que se dice que un Project Manager ahora cuenta con modelos, métodos y artefactos que puede aplicar “cuando sea necesario” y “cuantas veces sea necesario”, y también permite “usar otras herramientas que no se presenten en el PMBOK”. Y listo.
En la versión 7 no se describen las herramientas, se enumeran o listan, mientras que en la versión 6 se detallan, ilustran e incluso se ejemplifican.
Ahora el Project Manager, no se limita a unas cuantas herramientas prescritas por una guía cualquiera de gestión de proyectos, sino que ahora debe prepararse en manejar criterios para seleccionar e introducir en la gestión del proyecto cualquier herramienta siempre que aporte valor, calidad, excelencia, etc. al trabajo.
La Guía de Proyectos.
Obviamente será la PMBOK Guide, es decir, el PMBOK versión 6, pero podría ser otra, como PRINCE2, Agile, PM2, ITIL, o cualquier otra. Y esto no es menor, pues enriquece la actividad profesional del Project Manager y se aumenta la universalidad del PMBOK.
Ahora el Project Manager sabe que debe tener una base de ejecución de la gestión del proyecto, en general la PMBOK Guide, y en particular alguna otra. O la combinación que se crea necesaria.
Corolario.
Bueno, el PMBOK versión 7 fascina, es una forma de decirlo, porque expone la riqueza de la actividad de la gestión de proyectos y expone con nitidez que un Project Manager es quien toma decisiones y diseña estrategia proyectuales.
Fuente: este post proviene de Blog sobre diseño de proyectos, donde puedes consultar el contenido original.
¿Vulnera este post tus derechos? Pincha aquí.
Creado: