Actualización de publicaciones del Project Management Institute (III): "PMBOK Guide 8th edition"

Y con este post cierro la pequeña serie de artículos, tres incluyendo éste, dedicados a las últimas publicaciones del PMI ('Project Management Institute').

Tras haber comentado el estándar para gestión de proyectos y el estándar específico de inteligencia artificial, llega el momento del 'documento estrella' del PMI, es decir, el PMBOK ('Project Management Book Of Knowledge') o, como el PMI puntualiza la guía al PMBOK. 

El contenido del PMBOK

En esta octava edición, el PMBOK (documento de unas 270 páginas), se estructura en cinco capítulos y cinco apéndices. Los capítulos son:

• 1. Introduction: Un breve introducción explicando la estructura del documento, la relación con el estándar y los principales cambios respecto a la edición anterior


• 2. Project Management Performance Domain El capítulo más largo y que aporta mayor estructura y conceptos, describe los denominados 'performance domains' (algo así como dominios de desempeño) que, aunque quieren evitar el nombre, son una especie de procesos de alto nivel. Los dominios son:
  
  
  • Gobernanza ('Governance')
  • Alcance ('scope')
  • Planificación ('schedule')
  • Finanzas
  • Interesados ('stakeholders')
  • Recursos ('resources')
  • Riesgos
  
  
  Por cada uno de estos dominios, y salvo en el caso de la gobernanza en que añade alguna sección adicional, las estructura del discurso es siempre la misma:
  
  
  • Conceptos principales que, en esencia, aporta definiciones más o menos explicadas, de los conceptos utilizados
  
  
  • Procesos que componen el dominio indicando, aparte de la estructura general de procesos, un cierto detalle de cada proceso en que, aparte de una explicación se esquematiza sus entradas y salidas, y las herramientas y técnicas habitualmente utilizadas. Tantos las entradas y salidas como las herramientas y técnicas sólo se encuentra enunciadas porque la explicación se proporciona en otros capítulos
  
  
  • Consideraciones sobre personalización
  
  
  • Interacción con otros dominios
  
  
  • 'Checklist' de comprobación de resultados ('outcomes').


• 3. Tailoring Un capítulo no muy largo sobre la personalización / adaptación del marco general a casos concretos donde se argumenta el por qué de esa adaptación, se identifica qué elementos de adaptan y se describe un poco ese proceso de adaptación / personalización.


• 4. Inputs and outputs Describe todas y cada una de las entradas o salidas que han aparecido en los procesos de los dominios vistos en el capítulo dos. Se trata del orden de cien entradas y o salidas, descritas siguiendo un orden meramente alfabético y aportándose en la mayoría de los casos poco mas que una definición aunque en ciertos casos se detiene bastante más.


• 5. Tools and techniques De forma muy similar a lo hecho con entradas y salidas, se censan por orden alfabético, todas las herramientas y técnicas que han aparecido en los procesos de los dominios. En este caso hablamos de una ciento setenta herramientas o técnicas. La descripción de cada una, de nuevo, es irregular, siendo en algunos caso meras definiciones pero, para otras, se aporta bastante detalle.

Tras esto, tenemos cinco apéndices:

• El primero con el listado de personas que han participado


• El segundo, de un cierto interés se ocupa de las PMO ('Project Management Office')


• El tercero habla de inteligencia artificial pero sin grandes aportaciones y supongo que preparando el terreno para lo que sería el estándar que hemos comentado en otro post.


• Un cuarto apéndice, muy bien desarrollado e interesante sobre 'procurement' que, quizá, debería haberse encajado de alguna forma en el cuerpo principal del PMBOK


• Finalmente una descripción de cómo ha ido evolucionando el PMBOK a lo largo del tiempo.

Mi valoración

Creo que la mayor diferencia de esta edición (la octava) frente a la séptima edición (que, sinceramente, creo que era muy floja) son los dos capítulos dedicados tanto a entradas y salidas como, sobre todo, el de técnicas y herramientas.

Estos dos nuevos capítulos que, en el fondo, son un complemento a la descripción de los procesos del capítulo segundo dedicado a los dominios de desempeño, aportan valor, información y rigor y recuperan parte de lo que se perdió con esa creo que desgraciada séptima edición del PMBOK.

Aunque  no he hecho una comparación rigurosa, creo que, aún, la primera edición del PMBOK que yo conocí (la que estaba vigente cuando me certifiqué como PMP), la quinta y probablemente la sexta eran más sólidas y estructuradas, pero aún así, esta octava edición reconcilia un tanto con el PMBOK y recupera parte de lo perdido en la séptima edición.

No obstante, sigo sin entender, o tal vez compartir, la diferenciación entre el estándar y el PMBOK que creo que no tiene sentido tal y como está planteada actualmente.

 Igualmente, y de cara a futuras ediciones, creo que sería bueno seguir profundizando en la parte de entradas y salidas y las técnicas y herramientas, alargando más las descripciones y entrando más en materia porque gran parte del conocimiento real y práctico de la disciplina de dirección de proyectos recae en ellas.

Conclusiones

Hemos revisado el contenido del PMKOK (guía del PMBOK realmente) en su octava edición y, aunque creo que tiene margen de mejora, recupera una parte importante del rigor y profundidad perdidos en la séptima edición.

Artículos de este blog relacionados

• Actualización de publicaciones del Project Management Institute (II): "The standard for artificial intelligence"
• Actualización de publicaciones del Project Management Institute (I): "The standard for project management"

Actualización de publicaciones del Project Management Institute (II): "The standard for artificial intelligence"

En este breve recorrido por tres documentos recientes y relevantes emitidos por el PMI ('Project Management Institute'), le llega el momento a un documento, un estándar, dedicado al campo de la inteligencia artificial. 

El nombre del documento es 'The Standard for Artificial Intelligence in Portfolio, Program, and Project Management' y es de muy reciente publicación, en concreto de Junio de 2026, así que, en el momento de redactar este post, no tiene ni dos meses de vida.

Se trata de un estándar que me generó mucho interés porque une una de mis áreas de investigación de mayor interés, la inteligencia artificial, con un área de 'expertise' en gestión como es la dirección de proyectos y porque me parecía importante ver qué tenía que decir la mayor autoridad en dirección de proyectos sobre el caso concreto de la inteligencia artificial

¿Qué me he encontrado?

El contenido del "Standard for Artificial Intelligence in Portfolio, Program, and Project Management"

Nos encontramos ante un documento de mediana extensión, cercana a las 300 páginas.

Antes de ver un poco el contenido, alguna tema relevante a tener en cuenta.

Aunque personalmente tiendo a hablar de forma un poco genérica de dirección de proyectos, en este documento, y siguiendo el modelo del PMI, se distingue entre proyectos, programas y porfolios y, en varios puntos del estándar, la distinción es nítida.

El estándar distingue, y me parece un acierto, entre la IA como producto, como resultado de proyectos, programas y porfolios y la IA como una herramienta utilizable en la propia dirección de proyectos, programas y porfolios. 

Dicho esto, el contenido del documento se estructura en siete capítulos, a saber:

• 'Introduction:' Una introducción al contenido e intenciones del estándar junto con algún recordatorio de conceptos sobre dirección de proyectos y sobre inteligencia artificial.


• 'Principles of AI in Project, Program and Porfolio Management:' De la misma forma que el estándar para dirección de proyectos, programas y porfolios establece seis principios, aquí se establecen ocho principios que, aunque se parecen, no son los mismos que los generales. Sin entrar en detalles, sólo señalar cuáles son los principios para el caso de proyectos en materia de inteligencia artificial:
  
  
  • Valor estratégico: es decir, foco en la creación de valor.
  • Riesgo: que enfatiza la necesidad de supervisión humana.
  • Gobernanza y cumplimiento normativo: orientado por un lado al alineamiento estratégico y, por otro, al respeto a la legislación y a los principios éticos.
  • Personas y cultura: desglosando entre liderazgo y el equipo de proyecto.
  • Ética y responsabilidad profesional: con foco fundamentalmente en la supervisión humana y en la responsabilidad en el sentido de rendición de cuentas.
  • Involucración de partes interesadas ('stakeholder engagement'): alineando los proyectos con las expectativas de esas partes interesadas.
  • Optimización e innovación: anima a la adopción de nuevas tecnologías y metodologías para conseguir mayor eficiencia, adaptación y calidad.
  • Calidad del dato: como mecanismo para conseguir resultados de calidad, a su vez.


• 'Performance Domains of AI in Project, Program and Porfolio Management:' Establece cinco dominios ('performance domains') que se asemejan, pero no coinciden, con los dominios identificados en el PMBOK, del que hablaremos en otro post. Los dominios para el caso de la IA serían, según este estándar, los siguientes:
  
  
  • Gestionar las expectativas de las partes interesadas sobre la IA
  • Definir el alcance de la IA
  • Definir una arquitectura IA con calidad y responsabilidad
  • Ejecutar objetivos estratégicos
  • Gestionar riesgos e incertidumbres


• 'Life Cycle management and tailoring activities:' Revisa muy brevemente los ciclos de vida predictivos, adaptativos e híbrido y su traslado a proyectos de IA y luego trata tanto las actividades de personalización ('tailoring') como de ciclo de vida y optimización distinguiendo en ambos casos entre proyectos, programas y porfolios.


• 'AI in the context of Project, Program and Porfolio Management:' hace el cambio de perspectiva a la aplicación de la IA no como producto sino en la propia actividad de dirección de proyectos, programas y porfolios aportando alguna idea sobre cómo usarla


• 'Framework for the use of AI in Project, Program and Porfolio Management:' Aporta un marco con unos pasos y consideraciones a tener en cuenta en la dirección de proyectos, programas y porfolios, centrándose en cuatro áreas: establecimiento de un caso de negocio, uso de la IA en proyectos, programas y porfolios, flujo de información y ajuste cultural y organizativo.


• 'Ethical and Legal considerations for AI use in Projects, Programs and Porfolios:' realiza alguna propuesta en los ámbitos ético y legal, como la existencia de un comité ético

En dos anexos finales identifica, por un lado, algunos esquema de evaluación de la madurez en IA y, por otro, leyes y regulaciones a tener en cuenta. 

Mi valoración

Siendo sincero, debo reconocer que este estándar me ha decepcionado y que soy bastante crítico con él.

Antes de la crítica, decir que me parece bueno que exista este estándar, o al menos una guía en este campo, por parte del PMI, y que me parece acertada la distinción entre la IA como producto de proyectos y el uso de la IA para la propia dirección de proyectos, programas y porfolios.

Pero mi visión positiva casi se acaba aquí y en seguida comienza mi crítica.

En primer lugar, y como ya expresé a propósito del "Standard for project management", esto no me parece un estándar, por más que se encuentre respaldado por ANSI. No es prescriptivo, no es asertivo, no es demasiado accionable y no es claramente certificable. En mi opinión, es más una guía o un marco de trabajo, pero no un estándar, que ANSI y el PMI me perdonen.

Por otro lado, y casi como extensión de lo anterior, lo veo muy ligero, de muy alto nivel, muy de intenciones o ideas, pero de poco detalle y 'accionabilidad'.

Creo que no es demasiado acertado al tratar de forma genérica los proyectos de inteligencia artificial sin distinciones nítidas de tipologías. En mi opinión tiene poco que ver, a nivel de ciclo de vida y gestión, un proyecto de machine learning tradicional como la creación de un modelo predictivo personalizado para una empresa, con el desarrollo de un agente, por ejemplo. 

Me sorprende, y me parece incoherente, que los principios y dominios que se identifican en este supuesto estándar sobre IA, sean diferentes, en lugar de ser una particularización, de los genéricos de dirección de proyectos identificados en el estándar de dirección de proyectos, o los dominios identificados en el PMBOK. Eso es tanto como decir que los principios y dominios genéricos no son tan genéricos, sino que diferentes tipologías de proyectos pueden necesitar principios y dominios diferentes y cuestionar los genéricos.  Como mucho, podría entender que se añada alguno principio o dominio nuevo, pero no que se redefinan todos. No tiene sentido.

También me parece incoherente que si en el caso de la documentación general del PMI, los principios se encuentran en el estándar de proyectos y los dominios y la personalización ('tailoring') en el PMBOK, aquí, en el caso de la IA, todo quepa en el estándar.

En fin, que me ha resultado bastante decepcionante.

Conclusiones

Entre los documentos más recientes lanzados por el PMI se encuentra el estándar para proyectos, programas y porfolios de inteligencia artificial.

Una, en mi opinión, buena iniciativa pero con un resultado, también en mi opinión, criticable y bastante decepcionante.

Artículos de este blog relacionados

• Actualización de publicaciones del Project Management Institute (I): "The standard for project management"

Actualización de publicaciones del Project Management Institute (I): "The standard for project management"

Con este post inicio una serie corta de tres artículos (que probablemente se intercalen con posts de temáticas completamente diferentes) en que comentaré y valoraré brevemente algunas de las últimas publicaciones del PMI ('Project Management Institute'), la probablemente autoridad más reconocida a nivel mundial en materia de dirección de proyectos. 

En ellos, uno en cada post, comentaré brevemente tres documentos, a saber:

• The standard for project management (ANSI/PMI 99-001-2025)
• A guide to the Project Management Book Of Knowledge. PMBOK Guide. 8th edition.
• The Standard for Artificial Intelligence in Portfolio, Program, and Project Management

Antes de los breves comentarios, una pequeña explicación acerca de mis motivaciones.

Motivaciones: la importancia de los proyectos y el PMP

Hasta que en 2018 inicié mi andadura profesional por cuenta propia bajo mi marca 'Reingeniería digital', una parte muy importante de mi carrera ha estado dedicada de una forma u otra a proyectos.

He formado parte de equipos de proyecto, he actuado como jefe de proyecto y director de proyecto de iniciativas de todo tipo, algunas sencillas pero otras muy ambiciosas y de alto presupuesto, y he dirigido equipos que, a su vez, dirigían proyectos.

Y cada vez más fui apreciando la disciplina de la dirección de proyectos y, aún más, la figura del jefe de proyecto. Esta importancia se me hizo especialmente patente cuando los proyectos a que nos dedicábamos estaban dirigidos a clientes pertenecientes a las grandes cuentas de Telefónica Empresas, donde se encontraban la mayor parte de empresas del IBEX y muchas otras empresas y administraciones de gran tamaño y presupuesto. Llegué al profundo convencimiento de lo importante que era la figura del jefe de proyecto para alcanzar el éxito y no me refiero sólo a la figura en sí como un rol abstracto, que también, sino a la cualificación y voluntad de las personas concretas que ejercían ese rol. La relación con el cliente y el éxito de los proyectos, dependían en buena medida de esa figura y de la persona que la ejerciese. 

En 2012, cuando ya realmente no ejercía como director de proyecto sino como gerente, decidí, a pesar de ello, obtener la certificación PMP ('Project Management Professional'), lo cual sucedió en Junio de 2012, hace ahora catorce años, a lo largo de los cuales, y como establece el PMI, he ido renovando esa certificación que aún tengo en vigor y que pienso volver a renovar el año que viene.

Cuando obtuve la certificación, el PMBOK vigente se encontraba en su quinta edición. Desde entonces he adquirido y estudiado las siguientes ediciones, la sexta, la séptima... y ahora le toca a la octava, publicada en Enero de 2025.

Además, me interesó mucho conocer, dado mi interés y dedicación a la inteligencia artificial, que PMI junto con ANSI, habían lanzado también un estándar para proyectos de inteligencia artificial.

La idea, pues, ha sido realizar una nueva actualización y, en este caso, además, compartir con los lectores de este blog un poco del contenido objetivo de los documentos, y otro poco de mi valoración personal. 

Explicado esto, vamos con el primero de los documentos, el 'Standard for project management'

El contenido del "Standard for Project management"

Este estándar ha sido definido mediante una colaboración entre el PMI ('Project Management Institute') y ANSI ('American National Standards Institute'), colaboración que se inició, si la memoria no me falla, con la anterior versión del PMBOK (la séptima).

Aunque se trata de un documento separado, se publica en el mismo volumen que el PMBOK, del cual hablaré en otro post de esta serie.

Según reza en el propio documento, este estándar

provides a basis for understanding project management and how it facilitates intended outcomes.

y, un poco más abajo, dice

The standard describes how project management creates value and benefits in organizations as well as how organizational and project leaders can harness the power of project management for success.

 

Como se pude deducir un poco de estas declaraciones de intenciones, y como insistiré en mi comentario personal, se trata de un documento más descriptivo que normativo.

El documento de poco más de setenta páginas  y se estructura en cuatro secciones:

• 'Introduction': Establece el propósito del estándar, proporciona un vocabulario de términos y conceptos y ataca algunos aspectos generales de los proyectos como sus características, conceptos de gobernanza, relación con las operaciones de la compañía y las relaciones entre los conceptos de proyecto, programa, porfolio y operaciones.


• 'System for value delivery': Extendiendo lo ya iniciado en la séptima edición, adopta una visión muy de alto nivel y negocio para hablarnos de cómo los proyectos aportan valor y se sitúan como parte de un sistema de valor. Propone un modelo para conceptualizar ese sistema de valor y a partir de ahí comenta elementos de contexto interno y externo a proyectos, programas y porfolios, establece la relación con el 'product management' e identifica una serie de funciones y roles presentes en los proyectos.


• 'Project management principles': Identifica y explica seis principios de la dirección de proyectos, a saber:
  • Adoptar una visión holística
  • Enfocarse en el valor
  • Introducir la calidad en los procesos y los entregables
  • Ejercer un liderazgo responsable
  • Integrar la sostenibilidad en todas las áreas de proyecto
  • Construir una cultura de empoderamiento


• 'Project Life Cycles': Habla de las fases de los proyectos y luego identifica los tres grandes enfoques para la dirección de proyectos (predictivo, adaptativo e híbrido) y proporciona criterios para seleccionar un enfoque u otro. También habla de la cadencia de las entregas, mencionando el despliegue continuo propio de DevOps (aunque sin mencionar a DevOps). Finaliza identificando y describiendo las que denomina cinco áreas de foco, a saber:
  • Inicio
  • Planificación
  • Ejecución
  • Monitorización y control
  • Cierre

Una valoración: ¿Esto es un estándar?

Este estándar es un documento correcto y bien redactado (aunque en el típico estilo profesional austero) y que proporciona un vocabulario y una especie de marco de referencia común, eso sí, un poco abstracto y de bastante alto nivel.

Me parece bueno, a nivel de una disciplina, establecer ese marco de referencia y ese vocabulario comunes y no me parece mal, tampoco, comenzar por un alto nivel para luego ir bajando.

Sin embargo, insisto, es muy alto nivel y en algunas partes un poco abstracto. Le falta mucho bajar a tierra, en mi opinión. si pretende orientar realmente la acción de las organizaciones y de los profesionales.

Y aunque esto sea enmendarle la plana nada más y nada menos que a ANSI, me resisto a ver este documento como un verdadero estándar, porque no detalla nada, no da pautas asertivas, no obliga a nada y no es muy verificable si se está aplicando o no.

La verdad es que esto no es lo que yo entiendo por un estándar.

Hace muchos años, en mis primeros tiempos en Telefónica, me miré muchas normas y estándares del ámbito de las telecomunicaciones, que definían, por ejemplo, protocolos y, desde luego, no tiene nada que ver con esto. Aquello era detalladísimo, normativo, verificable y, todo hay que decirlo, muy farragoso,

No he tenido mucha ocasión de leer directamente estándares o normas del ámbito industrial pero, hasta donde sé, son de nuevo, muy detalladas, muy concretas y completamente verificables en su cumplimiento.

Este documento, pues, lo veo como divulgativo, conceptual e introductorio pero, por mucho que lo firme ANSI, me resisto a verlo como un verdadero estándar.

Conclusiones

Inicio con este artículo, una breve serie de tres posts dedicados a documentos más o menos recientes emitidos por el PMI ('Project Management Institute')

En este primer post, comento brevemente el 'The Standard For Project Management', un documento conceptual y de alto nivel, que establece vocabulario y conceptos, pero que no entra en detalles y que me cuesta mucho verlo como un verdadero estándar.

Una decepcionante versión 7 del PMBOK de PMI

El Project Management Institute es la autoridad de facto en materia de dirección de proyectos y la entidad emisora del prestigioso certificado PMP ('Project Management Professional') que me honro en poseer. Y el conocido popularmente como PMBOK, aunque su titulo real es 'Guide to the Project Management Body Of Knowledge', es decir, una guía al cuerpo de conocimiento en dirección de proyectos, es sin duda, su publicación fundamental. Este volumen es, en el momento de editar esta reseña, la última edición de ese documento, la séptima, en concreto.

Una edición que cambia de manera bastante radical el contenido y orientación de las ediciones anteriores, al menos las que yo he conocido desde que me certifiqué (cosa que hice con base en la edición 4).

Lo cambia en el sentido de hacer un enfoque mucho menos de metodología y más de principios e ideas generales. Lo cambia en el sentido de hacerlo más breve y creo que superficial y lo cambia en el sentido de que, además, del PMBOK propiamente dicho, incluye lo que se ha convertido en un estándar ANSI.

El volumen, pues, es en realidad la unión de dos documentos, cosa que me resultó un poco confuso cuando lo leí.

Se comienza por el estándar en el documento 'THE STANDARD FOR PROJECT MANAGEMENT' que consta de tres capítulos, a saber:

• '1. INTRODUCTION': Un muy breve capítulo introductorio en que señala el objetivo del estándar, define algunos términos básicos y anuncia la audiencia esperada del documento.


• '2. A SYSTEM FOR VALUE DELIVERY': Situa a los proyectos dentro de una especie de ecosistema de entrega de valor. Comienza, precisamente, mostrando ese sistema de entrega de valor que incluye los proyectos como tales pero agrupados en programas y porfoliosdando entrada también a las operaciones. Habla brevemente de los sistemas de gobierno y salta a continuación a identificar y explicar ocho funciones asociadas a los proyectos. En la siguiente sección identifica brevemente una serie de elementos de contexto tanto internos (en la propia empresa) como externos, que afectan a los proyectos. Y, finalmente, y de nuevo brevemente, pone los proyectos en relación con el ciclo de producto.


• '3. PROJECT MANAGEMENT PRINCIPLES': Identifica y desarrolla, en dos o tres páginas cada uno, los principios que guian la dirección de proyectos y que son los siguientes:
  • Sé un administrador diligente, respetuoso y cuidadoso
  • Crea un entorno colaborativo del equipo del proyecto
  • Involúcrate eficazmente con los interesados
  • Reconoce, evalua y responde a las interacciones del sistema
  • Demuestra comportamientos de liderazgo
  • Adapta en función del contexto
  • Incorpora la calidad en los procesos y los entregables
  • Navega en la complejidad
  • Optimiza las respuestas a los riesgos
  • Abraza la adaptabilidad y la resiliencia
  • Permite el cambio para lograr el estado futuro previsto

Tras esto, se aborda ya el PMBOK, en el documento'A GUIDE TO THE PROJECT MANAGEMENT BOOK OF KNOWLEDGE' que consta de cuatro capítulos:

• '1. INTRODUCTION': Capítulo introductorio breve donde indica la estructura del documento y también la relación de este PMBOK con el estándar que acabamos de ver, fundamentalmente relacionando los principios definidos en el estándar con los dominios de desempeño que se desarrollan en el PMBOK. Y señala finalmente, algunos cambios respecto a la edición anterior.


• '2. PROJECT PERFORMANCE DOMAINS': 'Un capítulo nuclear donde identifica y desarrolla los ocho dominios del desempeño de proyectos, a saber:
  • Interesados ('stakeholders')
  • Equipo
  • Enfoque de desarrollo y ciclo de vida
  • Planificación
  • Trabajo del proyecto
  • Entrega
  • Medida
  • Incertidumbre


• '3. TAILORING': ' Un capítulo que explica cómo adaptar elementos de proyecto como el enfoque de desarrollo, el ciclo de vida o los dominios de desempeño a las circunstancias particulares de cada proyecto.


• '4. MODELS, METHODS AND ARTIFACTS': ' Un capítulo que censa y explica, aunque sin profundidad, un amplio catálogo de técnicas usadas habitualmente en proyectos y que agrupa en tres bloques:
  • Modelos: estrategias de pensamiento. Menciona varios de ellos y en una tabla/matriz final relaciona estos modelos con su uso en los diferentes dominios de desempeño.
  • Métodos: medio para conseguir unos resultados y que identifica agrupándolos en cuatro bloques: métodos para toma de datos y análisis, métodos para estimación, métodos para reuniones y eventos y otros. Como en el caso anterior cierra con una tabla / matriz que relaciona los métodos con su uso en dominios de desempeño.
  • Artefactos: plantillas, documentos, etc que identifica agrupados en nueve bloques: estrategia, registros, planes, organigramas, líneas base, información y datos visuales, informes, acuerdos y contratos y otros. Al final, y como en los dos casos anteriores, se ofrece una tabla/matriz con el uso de esos artefactos en los diferentes dominios de desempeño.

Aparte de las dos obras mencionadas, el volumen incluye 5 anexos. El primero es un simple, aunque extenso, listado de las personas que han contribuido aportando contenido o como revisores. Los tres siguientes hacen foco sobre tres temas concretos como son los espónsors, la PMO ('Project Management Office') y la gestión de productos. El último habla de la investigación realizada para la elaboración del estándar.

Aparte de la existencia de dos documentos, algunos otros elementos diferenciales de esta versión son el foco en los principios que se detallan en el estándar y el cambio de la orientación a procesos y áreas de conocimiento de las ediciones anteriores, a los dominios de desempeño de ésta. Además, y quizá es lo único que me quedo que realmente me haya aportado valor, y aunque ya se había anticipado bastante en las versiones anteriores, es con el discurso de las orientaciones de proyecto y ciclo de vida, que puede ser un buen marco conceptual para encajar waterfall/predictivo, agile y opciones intermedias.

Y al referirme a los enfoques de proyectos he dicho que es con lo único que me quedo porque, para ser sincero, esta edición del PMBOK, así como el propio estándar, me han decepcionado mucho. Valoro enormemente el rol de jefe de proyecto y director de proyecto, roles que ejercí con frecuencia hace unos pocos años, y estoy muy contento y orgullo de ostentar la certifición PMP. Y no puedo evitar percibir que esta edición del PMBOK incluye, no sólo un giro que no considero afortunado, sino, sobre todo, una suerte de 'descafeinado' de la información y de la propia disciplina, convirtiendo tanto al estándar como al PMBOK en documentos un tanto filosóficos o de puras intenciones e ideas generalistas y bastante superficiales. En lo relativo al estándar, no sé cómo un documento así se puede considerar un estándar cuando es tan especulativo, cuando no establece ni normas, ni procedimientos, ni procesos, ni plantillas, ni verificaciones. Nada de nada. No sé que pretende estandarizar realmente.

Unos documentos, en fin, que creo que nada o poco aportan ni a un profesional de la dirección de proyectos ni a nadie que se quiera formar en la materia y que se acerque a este documento como quien se aproxima a una autoridad.

Espero que la octava edición retorne a una senda más parecida a la mantenida hasta la edición 6.

Una verdadera pena.

Ficha técnica:

TITULO: A Guide to the Project Management Book of Knowledge 7th and The Standard for Project Management

AUTOR: PMI (Project Management Institute)

EDITORIAL: PMI (Project Management Institute)

AÑO: 2021 

ISBN: 978-1636390314

PAGINAS: 250

No, Agile no significa ir más rápido

Con frecuencia, los nombres que se escogen para las tecnologías, y en ocasiones también para las disciplinas de gestión, son engañosos. A veces, ya sea por ignorancia o, creo más bien, con intenciones de naturaleza comercial, se eligen nombres que llaman a engaño y que hacen creer lo que no es.

Y eso ocurre con Agile, una, ¿cómo la llamaríamos? filosofía o disciplina de gestión de proyectos que se encuentra absolutamente de moda, aunque sus orígenes se remonten a muchos años atrás. Se trata de una filosofía que, simplificando un poco, se aplica en proyectos con requisitos poco claros o que se mueven en un entorno de incertidumbre (típicamente, proyectos de innovación o emprendimiento, y muchos proyectos de desarrollo software) y que se basa en construir el resultado mediante iteraciones cortas que producen resultados tangibles, por ejemplo, una nueva versión de software utilizable.

Pero  ¿qué sugiere el nombre de Agile? Pues, claro, agilidad, es decir, rapidez. 

Y así, de nuevo puede que en algunos casos por ignorancia y en otros intencionadamente, se ha asimilado agilidad o agilismo a rapidez y muchos gestores han implantado agile (o "cosas" que pretenden serlo) sólo en búsqueda de esa tierra prometida de la rapidez.

Agile significa adaptación

Pues va a ser que no: agile no significa ir más rápido. Agile, lo que significa, es ser adaptativo. 

Y esa capacidad de adaptación, eso sí, nos puede hacer avanzar más rápído en algunos casos.

¿Qué quiere decir esto? 

Pues que, dado que nos movemos en entornos de incertidumbre y de requisitos poco claros y cambiantes, renunciamos a definir clara y completamente el alcance al inicio del proyecto y renunciamos también a hacer una planificación de tareas, tiempos y recursos para toda la vida del proyecto. En lugar de eso, vamos avanzando en ciclos cortos (lo que Scrum denomina sprints), generando incrementalmente versiones del entregable final (un software, un producto, un modelo de negocio...). Y con base en lo que vemos y el entorno, deducimos cuáles son los nuevos requisitos y hacemos un nuevo incremento corto adaptado a esa realidad.

¿Es Agile más rápido?

¿Y eso es más rápido?

Pues no exactamente, o no necesariamente. Sólo en los contextos adecuados. 

De heco, y aunque no lo voy a detallar en este post (invito al lector a razonarlo), en un proyecto con requisitos claros y entorno estable (lo que desde hace un tiempo el Project Management Institute denomina proyectos predictivos) creo es más eficiente e incluso más rápida la gestión de proyectos tradicional.

Lo que ocurre, eso sí, es que cada vez son menos frecuentes esos proyectos predictivos. Y en entornos de incertidumbre y requisitos poco claros, Agile si que tiene las armas para ir más rápido. ¿Por qué? Pues porque las inevitables equivocaciones que se producen en un entorno de incertidumbre, se corrigen de forma muy costosa y lenta en un proyecto gestionado de forma tradicional, mientras que tienen un impacto menor, mucho menor, en Agile dado que como mucho nos equivocamos en un pequeño incremento. Así que esos errores inevitables se corrigen rápido y el proyecto en su conjunto, termina antes.

Además, Agile produce una "ilusión de rapidez" por aquello de que produce resultados tangibles en iteraciones cortas. Y por eso, el cliente, o la dirección o el mercado, ven resultados pronto y los observan crecer a buena velocidad. Estrictamente hablando, eso no es ir exactamente más rápido, el final se puede alcanzar en el mismo plazo, sino hacer visible los resultados antes. Pero esa estrategia de producir resultados en pequeños incrementos, aparte de ser pieza muy importante del mecanismo de adaptación, genera esa sensación, no realmente cierta pero sí útil y atractiva, de rapidez y agilidad.

Conclusión

Este es mi convencimiento y algo que suelo destacar en las ocasiones en que explico Agile a mis alumnos o clientes.

Y me alegra ver que, aunque no sé si lo explicarían de la misma forma que yo, unas autoridades en el mundo de Agile, como son los autores del libro  'La empresa ágil' : Alonso Álvarez, Sara Aguilera, Susana Jurado y Míquel Rodríguez, van en una línea, al menos parecida, cuando indican:

tendemos a usar "ágil" como sinónimo de "rápido", pero en realidad también tiene una connotación de "flexible" y "adaptable".

Así que, recordemos, debemos usar Agile en entornos de incertidumbre y requisitos poco claros por muchas razones, incluido que nos pueden permitir terminar antes por gestionar mejor los cambios de alcance y requisitos. Pero no, Agile no significa realmente ir más rápido, Agile, lo que significa es ser adaptativo. La rapidez, en todo caso, se nos dará por añadidura.

La guía Agile de PMI y Agile Alliance

La 'Agile practice guide' es fruto de un trabajo conjunto entre PMI (Project Management Institute) y la Agile Alliance para hacer confluir, de alguna manera, la visión más tradicional y amplia del PMI con la muy específica de Agile y crear una guía práctica para éste segundo caso.

La guía, que es de una extensión media-corta, se estructura en siete capítulos:

• '1- Introduction' comienza hablando de los enfoques predictivo y agile y luego presenta la guía con una explicación de los capítulos que la componen.


• '2- Introduction to agile' habla brevemente de los proyectos de alta incertidumbre (donde encuentra su territorio natural el enfoque agile). Luego explica el manifiesto agile y la actitud que supone. Habla brevemente de Lean y Kanban y finaliza con unas consideraciones sobre la incertidumbre y la complejidad en los proyectos.


• '3- Life cycle selection' Explica cuatro ciclos de vida (predictivo, iterativo, incremental y agile) y cuándo resultan adecuados. También habla de modelos mixtos.


• '4- Implementing agile: creating an agile environment' habla de cómo poner en marcha una iniciativa agile. Nos habla fundamentalemente de las personas: del equipo y los roles.


• '5- Implementing agile: delivering an agile environment' adopta un enfoque algo más metodológico y así, por ejemplo, introduce una serie de buenas prácticas agile: retrospectivas, preparación y refinamiento del backlog, reuniones diarias y demostraciones y revisiones. También habla de cómo resolver algunas problemáticas y del seguimiento y medida de proyectos en el enfoque agile.


• '6- Organizational considerations for project agility' comenta aspectos diversos y algo heterogéneos como gestión del cambio, cultura organizacional, contratos, oficina de proyectos, coordinación interequipos o estructura organizativa.


• '7- A call to action' Un breve cierre que anima a seguir en contacto con las comunidades agile y de dirección de proyectos.

A los capítulos propiamente dichos se une una larga serie de anexos:

• 'A1 PMBOK Mapping Explica brevemente cómo aplica al caso agile cada una de las áreas de conocimiento del PMBOK


• 'A2 Agile Manifesto Mapping estabece una correspondencia entre los valores del manifiesto agile y lo descrito en la guía


• 'A3 Overview of agile an lean framewors hace un repaso express por los diferentes frameworks agile, tocando Scrum, eXtreme Programming, Kanban, Crystal, Scrumban, Feature-Driven-Development (FDD), Dynamic Systems Development Method (DSDM) y Agile Unified Process. Además comenta alguna idea para escalar estos frameworks a equipos grandes o multiequipos.


• 'X1 Contributors and reviewers simplemente, listado de organizaciones y personas que han participado


• 'X2 Attributes that influence tailoring una guía de alto nivel para la personalización de agile


• 'X3 Agile suitability filter tools propone un modelo para evaluar lo apropiado de usar un enfoque agile

La 'Agile practice guide' es, creo, un librito oportuno que aporta una visión preliminar del mundo agile y cómo encaja con la visión de dirección de proyectos más tradicional. Es una guía correcta, que no brillante, y que sirve muy bien como introducción aunque probablemente precise de un estudio más detallado, tanto del framework agile de nuestra elección, como de la propia doctrina de dirección de proyectos contenida en el PMBOK.

Ficha técnica:

TITULO: Agile practice guide

AUTOR: Project Management Institute y Agile Alliance.

EDITORIAL: Project Management Institute

AÑO: 2017 

ISBN: 978-1628251999
PAGINAS: 210

Hacia una dirección de proyectos 'agile' con Gloria J. Miller

'Going Agile' es una visión amplia, aunque rápida, de las ideas y técnicas propias de las metodologías agile desde un punto de vista de dirección de proyectos y dibujando una estrecha relación entre esas técnicas y las áreas de conocimiento establecidas por el PMI (Project Management Institute) en su Project Management Body Of Knowledge (PMBOK).

El libro se compone de 18 capítulos y un anexo. Desde nuestro punto de vista, y aunque no se explicita en la estructura del libro, el contenido gira alrededor de tres grandes bloques.

El primer bloque, que abarcaría los cinco primeros capítulos, establece las características principales de las metodologías agile. Así, en el capítulo 1, 'Agile is an inovation' nos hace ver cómo, si bien agile es una evolución desde el punto de vista metodológico, es sin embargo una revolución desde la perspectiva del liderazgo y dirección de proyectos y resume los beneficios de agile basándose en un estudio de Standish Group. En el capítulo 2, 'The Rational for Agility Manifesto', introduce el Agile Manifesto y repasa las formas en que Agile mejora los resultados de la dirección de proyectos, además de explorar la aplicabilidad de las técnicas agile. En el tercero, 'Methodoloy Comparison', hace una rápida comparativa entre las metodologías agile y las que tradicionales, que denomina dirigidas por planificación. En el cuarto 'Agile Practices' es donde resume las principales características de agile atendiendo a temas como el ciclo de vida, la figura del coach, la organización del proyecto, etc. Finalmente, en el quinto, 'The Agile Coach', se centra en esta figura tan relevante y diferencial de las metodologías agile: el coach y profundiza en los aspectos de liderazgo, construcción de equipo y resolución de conflictos.

El segundo bloque, el más largo, y que abarca desde el capítulo 6 hasta el 15, es un repaso cómo encajan las técnicas agile dentro de las áreas de conocimiento del PMBOK (Project Management Body Of Knowledge), el estándar de facto en dirección de proyectos apadrinado por el PMI (Project Management Institute). Así, se dedica un capítulo a la gestión de la Integración, Alcance, Tiempo, Costes, Calidad, Recursos Humanos, Comunicaciones, Riesgo, Compras, y Stakeholders. Quizá conviene destacar, por lo diferencial de las metodologías agile, los aspectos de alcance con el concepto de 'user story' como vehículo para la especificación y el backlog como repositorio de todo aquello que se quiere hacer en algún momento. También muy relevante es el capítulo de Recursos Humanos donde se clarifican las características especiales de un equipo agile, sus roles y mecánicas.

El tercer bloque, compuesto por tres capítulos, se orienta ya a la acción y así, en el capítulo 16 'Selecting an Agile Project Approach' da pistas acerca de cómo seleccionar la metodología agile más adecuada y cómo personalizarla o adaptarla a las necesidades particulares. El capítulo 17 'Going Agile' nos habla de cómo introducir Agile en la compañía abordando temáticas muy relacionadas con la gestión del cambio así como estrategias para facilitar la introducción. El capítulo 18 'Scaling Agile' continúa con el anterior pero ahora suponiendo que ya se ha introducido un agile y centrándose en cómo extenderlo ya de forma masiva.

El cuarto bloque está integrado por un anexo final en que, de forma muy breve, se repasan las principales metodologías agile: DSS (Dynamic Systems Development Method), FDD (Feature-Driven Methodology), Lean, Kanban, Scrum, eXtreme Programming, Crystal, etc

'Going Agile' es un libro ordenado, riguroso y bien documentado, que da una visión estructurada de la panorámica agile y su relación con el cuerpo de doctrina de dirección de proyectos contenido en el PMBOK. Quizá se le podría achacar, tal vez en aras de ese rigor, una cierta frialdad, la falta de una cierta 'pasión'. Parece, finalmente, que para una adecuada comprensión de agile, se necesita acompañar este libro de la lectura más profunda de una metodología concreta, que permita obtener una mejor idea de qué es agile en realidad.

Con todo, y si lo que se quiere es una visión general sin particularizar en metodologías específicas, 'Going Agile' cumple con creces los objetivos y es una lectura valiosa en ese sentido.

Gloria J. Miller:

Gloria J. Miller es fundadora y consultora jefe en Maxmetrics. Proporciona consultoría sobre la gestión de proyectos complejos y la consecución del cambio organizacional. Antes de fundar Maxmetrics, Gloria ocupó puestos de consultoría, liderazgo y dirección en SAS Institute, Oracle, CDI, Ultra Tech, and MCI Telecommunications.

Con más de 20 años de experiencia, Gloria ha realizado consultoría para diferentes administraciones y empresas del Fortune 500 así como conferencias en más de 26 países sobre diferentes temas en el campo de las Tecnologías de la Información. Es autora de metodologías y libros acerca de la implementación y despliegue de software y modernización de las organizaciones para el uso más efectivo de la información.

Gloria posee un posgrado en administración de empresas y titulaciones en computación y tecnología electrónica. Es Certified ScrumMaster (CSM), PMI-Agile Certified Practitioner (PMI-ACP®) y Project Management Professional (PMP®).

Puedes saber más sobre la autora en el sitio de su empresa, Maxmetrics o seguirla en twitter donde gestiona la cuenta de su empresa @maxmetrics.

Ficha técnica:

TITULO: Going agile. Project Management Practices.

AUTOR: Gloria J. Miller

EDITORIAL: Maxmettrics

AÑO: 2012

ISBN: 978-0-9886483-2-6

PAGINAS: 442

Artículos de este blog relacionados

• Aplicando los principios lean al mundo del software: 7 fuentes de desperdicio a eliminar
• Seis criterios para elegir una metodología Agile
• El trabajo individual también es ágil
• Proyectos Agile e inteligencia colectiva
• Los beneficios de Agile

Presentación: Fundamentos de dirección de proyectos

Hace ya unos meses que deseaba iniciar una serie de presentaciones, acompañada por su texto teórico, sobre la disciplina de dirección de proyectos.

Por fin, este fin de semana he publicado la primera de la que, espero, sea una moderadamente larga serie.

Esta primera presentación hace una panorámica general de la disciplina, siguiendo el modelo de buenas prácticas promovido por el PMI.

Si desea leer una explicación más textual, puedes leer el texto de la microteoría en mi página personal (www.ignaciogavilan.com).

Ética y dirección de proyectos

Quizá sea una evolución personal, quizá sea una acuciante necesidad social, lo cierto es que cada vez considero más importantes los aspectos éticos en la propia actuación, no sólo en el ámbito privado sino también, y muy especialmente, en el ejercicio profesional.

La ética, no sólo proporciona satisfacción y equilibrio personales sino que, además, actúa como catalizador y lubricante necesario para que los engranajes sociales, laborales y económicos funcionen suavemente, con eficacia, y con eficiencia.

Ya hace unos días comentaba en este mismo blog la relación que encuentro entre confianza y eficiencia o, si se prefiere, entre desconfianza e ineficiencia, cómo la existencia de confianza, elimina controles y simplifica procesos, consiguiendo mejores resultados.

Aparte de otros efectos positivos, la observación de un comportamiento ético genera confianza en los demás, en nuestro superiores, colaboradores y colaterales, en nuestros clientes y nuestros socios. Y esa confianza genera, a su vez, eficacia y eficiencia.

La ética es, pues, un imperativo moral pero también una necesidad económica y operativa.

Es por esa doble visión, por su vertiente moral y personal por un lado, y por sus implicaciones económicas y operativas por otro, que considero cada vez más importante todo lo que tiene que ver con la ética.

En ese sentido, me agrada sobremanera observar cómo en la disciplina de la dirección de proyectos, una actividad que he ejercido durante años, la organización que marca de facto los estándares en dirección de proyectos, el PMI (Project Management Institute), exige asus afiliados y a todo aquel que ostente o aspire a una certificación a observar un código ético y de responsabilidad social, un código que se centra en los siguientes cuatro valores.

• Responsabilidad (responsibility): sentido de propiedad de las propias acciones y decisiones
• Respeto (respect): adecuado tratamiento de personas y recursos, con respeto por las personas y por las diversidades étnicas, culturales, etc
• Imparcialidad (fairness): objetividad en las decisiones
• Honestidad (honesty): conocimiento y entendimiento de la verdad y actuación conforme a ella.

Una más que loable política, una declaración de intenciones y un ejemplo a seguir por otras instituciones y, por supuesto, por todos los practicantes de la profesión de dirección de proyectos.

La dualidad exactitud versus precisión

Suena a lo mismo, ¿verdad?

¿Qué diferencia existe entre la exactitud y la precisión? En el lenguaje de la calle, seguramente no mucha.

Sin embargo, en un plazo muy breve, me he encontrado dos veces con esta distinción en dos ámbitos bastante diferentes, lo que me ha hecho fijarme más en ella y asignarle valor.

La primera ocurrencia pertenece al ámbito de la dirección de proyectos y se incluye en el PMBOK (Project Management Book of Knowledge) que recoge las mejores prácticas en dirección de proyectos del PMI (Project Management Institute) y se menciona a propósito de la gestión de la calidad.

La otra fuente es el libro 'Analítica Web 2.0' de Avinash Kaushik que hemos mencionado en los últimos artículos y que trata fundamentalmente de analítica web, pero que también incluye interesantes reflexiones sobre todo tipo de indicadores y cuadros de mando.

En ambos casos, la distinción es la misma, y se refiere a la toma de diferentes medidas del mismo fenómeno:

• Precisión (Precision): Implica que todas las medidas están agrupadas, con muy baja dispersión. En teoría el valor medido podría alejarse del real, pero las medidas son consistentes entre sí.
• Exactitud (Accuracy): Quiere decir que los valores se acercan más al real, al menos en su valor medio, pero puede existir más dispersión entre las medidas individuales.

La figura nos ayuda a entender mejor el concepto.

Ambos atributos son, por supuesto, deseables. Sin embargo, a la hora de tomar decisiones, Avinash Kaushik apuesta sin ambages por la precision.

¿Por qué?

Pues porque en el mundo de la analítica web existen pocas medidas completamente deterministas, claras y absolutamente reales, por lo que es más importante entender las tendencias y actuar sobre ellas que sobre los valores concretos.

En ese sentido, la coherencia que proporciona la precision es mucho más valiosa que la cercanía al valor real (pero con dispersión) que ofrece la exactitud.

Un consejo sin duda sabio, orientado a la decisión y que, probablemente, y como ya ha ocurrido en otras reflexiones de Avinash Kaushik reflejadas en este blog, sea aplicable a otro tipo de indicadores no procedentes del mundo de la analítica web.