Guía Pmbok®: Y El Estándar

Machine Translated by Google
GLOBO ESTÁNDAR
Una guía para el proyecto

Cuerpo de conocimiento de gestión
GUÍA PMBOK®
Séptima edición
Y El estándar
para la gestión de proyectos
ANSI/PMI 99-001-2021
PMI Séptima Edición Julio 2021

EL ESTÁNDAR PARA
GESTIÓN DE PROYECTOS
y
UNA GUÍA DEL PROYECTO
ÓRGANO DE ADMINISTRACIÓN
DEL CONOCIMIENTO
(GUÍA PMBOK®)
Séptima edición

Datos de catalogación en publicación de la Biblioteca del Congreso
Nombres: Project Management Institute, editorial.
Título: El estándar para la gestión de proyectos y una guía para el cuerpo de conocimientos de gestión de proyectos
(guía PMBOK).
Otros títulos: Guía del cuerpo de conocimiento de la dirección de proyectos (guía del PMBOK) | guía PMBOK
Descripción: Séptima edición. | Newtown Square, Pensilvania: Project Management Institute, Inc., [2021] | Incluye referencias
bibliográficas e indice. | Resumen: "En los últimos años, la tecnología emergente, los nuevos enfoques y los rápidos cambios del
mercado interrumpieron nuestras formas de trabajar, lo que impulsó la evolución de la profesión de gestión de proyectos. Cada
industria, organización y proyecto enfrenta desafíos únicos, y los miembros del equipo deben adaptar sus enfoques. para gestionar con
éxito los proyectos y entregar resultados.Con esto en mente, Una guía para el Fundamento de la Dirección de Proyectos (PMBOK®
Guide) - La séptima edición profundiza en los conceptos y construcciones fundamentales de la profesión. Esta edición, que
incluye The Standard for Project Management y PMBOK® Guide, presenta 12 principios de gestión de proyectos y ocho dominios de
desempeño de proyectos que son críticos para entregar resultados de proyectos de manera efectiva. Esta edición de la Guía
PMBOK® : Refleja la gama completa de enfoques de desarrollo (predictivo, tradicional, adaptativo, ágil, híbrido, etc.); Dedica una
sección completa a adaptar los enfoques y procesos de desarrollo; Expande la lista de herramientas y técnicas en una nueva sección,
"Modelos, métodos y artefactos"; Se enfoca en los resultados del proyecto, además de los entregables; y se integra con PMIstandards+,
brindando a los usuarios acceso a contenido que los ayuda a aplicar la Guía PMBOK® en el trabajo. El resultado es una guía moderna
que permite a los miembros del equipo del proyecto ser proactivos, innovadores y ágiles en la entrega de resultados del proyecto".
Proporcionado por el editor.
Identificadores: LCCN 2021011107 (imprimir) | LCCN 2021011108 (libro electrónico) | ISBN 9781628256642 (rústica)
| ISBN 9781628256659 (epub) | ISBN 9781628256666 (edición kindle) | ISBN 9781628256673 (pdf)
Materias: LCSH: Gestión de proyectos – Normas
Clasificación: LCC HD69.P75 G845 2021 (impresión) | LCC HD69.P75 (libro electrónico) | DDC 658.4/04–dc23
Registro de LC disponible en https://lccn.loc.gov/2021011107
Registro de libro electrónico de LC disponible en https://lccn.loc.gov/2021011108

Una guía de los fundamentos de la dirección de proyectos (Guía del PMBOK) -- Séptima edición y El estándar para la
dirección de proyectos
ISBN: 978-1-62825-664-2
Publicado por:
Project Management Institute, Inc.
Bulevar del campus 14
Newtown Square, Pensilvania 19073-3299 EE. UU.
Teléfono: +1 610 356 4600
Correo electrónico: atenció[email protected]

Internet: www.PMI.org
©2021 Project Management Institute, Inc. Todos los derechos reservados.
Nuestro contenido con derechos de autor está protegido por la ley de propiedad intelectual de EE. UU. que es reconocida por la
mayoría de los países. Para volver a publicar o reproducir nuestro contenido, debe obtener nuestro permiso. Visite http://www.pmi.org/
permissions para obtener más detalles.
PMI, el logotipo de PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT
JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION y el slogan HACIENDO LA GESTIÓN DE PROYECTOS
INDISPENSABLE PARA LOS RESULTADOS EMPRESARIALES. son todas marcas de Project Management Institute, Inc. Para obtener
una lista completa de las marcas comerciales de PMI, comuníquese con PMI
Departamento legal. Todas las demás marcas comerciales, marcas de servicio, nombres comerciales, imágenes comerciales, nombres de
productos y logotipos que aparecen en este documento son propiedad de sus respectivos dueños. Quedan reservados todos los derechos
no concedidos expresamente en el presente.
Para realizar un pedido o para obtener información sobre precios, comuníquese con Independent Publishers Group:
Grupo de editores independientes
Departamento de pedidos
814 Calle Franklin del Norte
Chicago, IL 60610 EE. UU.

Teléfono: 800 888 4741
Fax: +1 312 337 5985
Correo electrónico: [email protected] (solo para pedidos)
Impreso en los Estados Unidos de América. Ninguna parte de este trabajo puede ser reproducida o transmitida de ninguna forma o
por ningún medio, ya sea electrónico, manual, fotocopiado, grabación o cualquier sistema de almacenamiento y recuperación de
información, sin el permiso previo por escrito del editor.
El papel utilizado en este libro cumple con el Estándar de papel permanente emitido por la Organización Nacional de Estándares de
Información (Z39.48—1984).
10 9 8 7 6 5 4 3 2 1


darse cuenta
Las publicaciones de normas y directrices de Project Management Institute, Inc. (PMI), de las cuales el
documento contenido en este documento es uno, se desarrollan a través de un proceso de desarrollo de normas
de consenso voluntario. Este proceso reúne a voluntarios y/o busca la opinión de personas interesadas en el tema
tratado en esta publicación. Si bien PMI administra el proceso y establece reglas para promover la equidad en el
desarrollo del consenso, no redacta el documento y no prueba, evalúa o verifica de forma independiente la precisión
o integridad de cualquier información o la solidez de los juicios contenidos en su publicaciones de normas y directrices.
PMI se exime de responsabilidad por lesiones personales, daños a la propiedad u otros daños de
cualquier naturaleza, ya sean especiales, indirectos, consecuentes o compensatorios, que resulten directa o
indirectamente de la publicación, el uso de la aplicación o la confianza en este documento. PMI renuncia y no ofrece
ninguna garantía, expresa o implícita, en cuanto a la exactitud o integridad de cualquier información publicada en
este documento, y renuncia y no garantiza que la información en este documento satisfaga cualquiera de sus
propósitos o necesidades particulares. PMI no se compromete a garantizar el rendimiento de los productos o servicios
de ningún fabricante o vendedor individual en virtud de esta norma o guía.
Al publicar y poner a disposición este documento, PMI no se compromete a brindar

u otros servicios para o en nombre de cualquier persona o entidad, ni PMI se compromete a realizar ningún
deber adeudado por cualquier persona o entidad a otra persona. Cualquier persona que utilice este documento
debe basarse en su propio juicio independiente o, según corresponda, buscar el asesoramiento de un profesional
competente para determinar el ejercicio del cuidado razonable en cualquier circunstancia dada. La información y
otros estándares sobre el tema cubierto por esta publicación pueden estar disponibles en otras fuentes, que el
usuario puede desear consultar para obtener vistas adicionales o información no cubierta por esta publicación.
PMI no tiene poder ni se compromete a vigilar o hacer cumplir el contenido de este documento. PMI no
certifica, prueba ni inspecciona productos, diseños o instalaciones con fines de seguridad o salud. Cualquier
certificación u otra declaración de cumplimiento con cualquier información relacionada con la salud o la seguridad en
este documento no será atribuible a PMI y es responsabilidad exclusiva del certificador o autor de la declaración.

en

Prefacio
Cada vez que se comienza a trabajar en una nueva edición de The Standard for Project Management
y PMBOK® Guide, existe la oportunidad de considerar perspectivas globales sobre los cambios en la gestión
de proyectos y los enfoques utilizados para obtener beneficios y valor de los resultados del proyecto. En el
tiempo entre cada edición, ha ocurrido un mundo de cambios. Algunas organizaciones han dejado de existir y han
surgido nuevas organizaciones. Las tecnologías más antiguas han llegado al final de su vida útil, mientras que las
tecnologías que ofrecen capacidades completamente nuevas han evolucionado. Las personas que continúan en la
fuerza laboral han mejorado su pensamiento, habilidades y capacidades a medida que los nuevos participantes se
enfocan en comprender rápidamente su lenguaje profesional, desarrollar sus habilidades, desarrollar su perspicacia
comercial y contribuir a los objetivos de sus empleadores.
Sin embargo, incluso en medio de tales cambios, hay conceptos y construcciones fundamentales que
permanecen en su lugar. Continúa la comprensión de que el pensamiento colectivo produce soluciones más
holísticas que los pensamientos de un individuo. Y el hecho de que las organizaciones utilicen los proyectos como
un vehículo para entregar un resultado o resultado único perdura.
DISEÑO CENTRADO EN EL CLIENTE Y EL USUARIO FINAL
Mientras la sexta edición de la Guía del PMBOK® estaba en desarrollo y durante el desarrollo
de esta séptima edición, PMI se ha involucrado activamente con una amplia gama de partes interesadas
globales en sus experiencias con el uso de The Standard for Project Management y la Guía PMBOK® . Estos
compromisos han incluido:
ÿ Encuestas en línea a muestras representativas de partes interesadas de PMI;
ÿ Grupos focales con líderes de PMO, gerentes de proyecto, profesionales ágiles, equipo de proyecto
miembros, educadores y formadores; y
ÿ Talleres interactivos con profesionales en varios eventos de PMI en todo el mundo.

viii
Los comentarios y aportes enfatizaron colectivamente cuatro puntos clave:
ÿ Mantener y mejorar la credibilidad y relevancia de la Guía PMBOK® .
ÿ Mejore la legibilidad y la utilidad de la Guía del PMBOK® mientras evita el relleno excesivo
con nuevo contenido.
ÿ Detectar las necesidades de información y contenido de las partes interesadas y proporcionar

contenido de apoyo a la aplicación práctica.
ÿ Reconocer que existe un valor continuo para algunas partes interesadas en la estructura y el contenido
de ediciones anteriores para que los cambios mejoren sin negar ese valor.
MANTENER LA PERTINENCIA DE LA GUÍA PMBOK ®
Desde sus inicios como el Cuerpo de conocimientos de la dirección de proyectos (PMBOK) en 1987, la Guía
del cuerpo de conocimientos de la dirección de proyectos (Guía del PMBOK® ) ha evolucionado reconociendo que los
elementos fundamentales de la dirección de proyectos perduran. Su evolución no solo ha implicado un aumento en el
número de páginas, también ha implicado cambios significativos y sustantivos en la naturaleza del contenido. Una
muestra de algunos de esos cambios clave se refleja en la siguiente tabla:

viii
Evolución de los cambios clave en la Guía del PMBOK®
Guía PMBOK®
Cambios evolutivos clave
Edición
1996 • Distinguido como "una guía para el cuerpo de conocimiento", en lugar del cuerpo de conocimiento para el proyecto
administración.
• Reflejó el subconjunto del cuerpo de conocimientos de gestión de proyectos que es “generalmente aceptado”,
significado aplicable a la mayoría de los proyectos la mayor parte del tiempo con un consenso generalizado de que las prácticas
tienen valor y utilidad.
• Definió la gestión de proyectos como “la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del
proyecto para satisfacer o superar las necesidades y expectativas de las partes interesadas [énfasis agregado] de un
proyecto”.
• Decisión específica de cambiar a un estándar basado en procesos impulsado por el deseo de mostrar interacciones entre las
áreas de conocimiento; crear una estructura robusta y flexible; y reconocer que ISO y otras organizaciones de estándares
estaban estableciendo estándares basados en procesos.
Tercero (2004) • Primera edición en incorporar el logo “ANSI Standard” en la portada. • Primera
edición para designar formalmente el Estándar para la Gestión de Proyectos de un Proyecto separado y distinto del Marco de
Gestión de Proyectos y Cuerpo de Conocimiento.
• Material incluido “generalmente reconocido como buena práctica en la mayoría de los proyectos la mayor parte del
tiempo”. • Definió la gestión de proyectos como “la aplicación de conocimientos, habilidades, herramientas y técnicas a las
actividades del proyecto para cumplir con los requisitos del proyecto”.
Sexto (2017) • Primera edición para hacer una separación clara entre el estándar ANSI y la guía. • La primera vez que se
incorpora contenido “ágil” en el texto, no solo se hace referencia en los ejemplos. • Ampliación del material de
presentación del Área de conocimiento, incluidos los conceptos clave, las tendencias y las prácticas emergentes.
consideraciones de personalización y consideraciones para entornos ágiles/adaptativos.

ix
Al igual que las ediciones anteriores de The Standard for Project Management y la Guía PMBOK® , esta edición
reconoce que el panorama de la gestión de proyectos continúa evolucionando y adaptándose. Solo en los últimos 10 años, el
avance del software en todo tipo de productos, servicios y soluciones ha crecido exponencialmente. Lo que el software puede
permitir continúa cambiando a medida que la inteligencia artificial, las capacidades basadas en la nube y los nuevos modelos
comerciales impulsan la innovación y las nuevas formas de trabajar.
Los modelos organizativos transformados han dado lugar a nuevas estructuras de equipo y trabajo de proyectos, la
necesidad de una amplia gama de enfoques para la entrega de proyectos y productos, y un mayor enfoque en los resultados
en lugar de los entregables. Los colaboradores individuales pueden unirse a equipos de proyectos desde cualquier parte del
mundo, desempeñar una variedad más amplia de roles y permitir nuevas formas de pensar y trabajar en colaboración.
Estos cambios y más han creado esta oportunidad de reconsiderar las perspectivas para respaldar la evolución continua de
The Standard for Project Management y la Guía PMBOK® .
RESUMEN DE CAMBIOS
Desde 1987, The Standard for Project Management ha representado un estándar basado en procesos.
El Estándar para la gestión de proyectos incluido en la Guía del PMBOK® alineó la disciplina y la función de la gestión de
proyectos en torno a una colección de procesos comerciales. Esos procesos comerciales permitieron prácticas consistentes y
predecibles:
ÿ Eso podría documentarse;
ÿ A través del cual se podría evaluar el desempeño frente a los procesos; y
ÿ A través del cual se podrían realizar mejoras en el proceso para maximizar la eficiencia
y minimizar las amenazas.
Si bien son efectivos para respaldar las buenas prácticas, los estándares basados en procesos son prescriptivos por
su propia naturaleza. Con la gestión de proyectos evolucionando más rápidamente que nunca, la orientación basada en
procesos de las ediciones anteriores no se puede mantener de manera que refleje el panorama completo de la entrega de
valor. Por lo tanto, esta edición cambia a un estándar basado en principios para respaldar la gestión eficaz de proyectos y
centrarse más en los resultados esperados que en los entregables.

X
Una comunidad global de profesionales de diferentes industrias y organizaciones, en diferentes roles y que
trabajan en diferentes tipos de proyectos han desarrollado y/o proporcionado comentarios sobre los borradores del
estándar a medida que ha evolucionado para esta edición. Además, los colíderes y el personal de la Guía PMBOK® -
Séptima edición revisaron otros cuerpos de conocimiento y trabajos enfocados en la gestión de proyectos para identificar
los conceptos principales integrados en esos textos. Estos esfuerzos combinados mostraron una fuerte alineación y
respaldaron la validación de que los principios rectores de esta edición del estándar se aplican en todo el espectro de la
gestión de proyectos.
Hasta la fecha, la comunidad global de gestión de proyectos ha adoptado el cambio de este estándar hacia un
conjunto de declaraciones de principios. Las declaraciones de principios capturan y resumen los objetivos generalmente
aceptados para la práctica de la gestión de proyectos y sus funciones principales. Las declaraciones de principios
proporcionan parámetros amplios dentro de los cuales los equipos de proyecto pueden operar y ofrecen muchas formas
de permanecer alineados con la intención de los principios.
Usando estas declaraciones de principios, PMI puede reflejar la gestión eficaz de proyectos en todo el panorama
de entrega de valor: predictivo a adaptativo y todo lo demás. Este enfoque basado en principios también es consistente
con la evolución de The Standard for Program Management (Tercera y Cuarta Ediciones) y The Standard for Portfolio
Management - Cuarta Edición. El Estándar para la Gestión de Riesgos en Portafolios, Programas y Proyectos y Gestión
de Realización de Beneficios: Una Guía Práctica
representan nuevos productos estándar desarrollados intencionalmente con un enfoque basado en principios por
equipos globales de expertos en la materia.
Nada en esta edición de The Standard for Project Management o A Guide to the Project
El cuerpo de conocimiento de gestión niega la alineación con el enfoque basado en procesos del pasado
ediciones. Muchas organizaciones y profesionales continúan encontrando útil ese enfoque para guiar
sus capacidades de gestión de proyectos, alineando sus metodologías y evaluando su proyecto
capacidades de gestión. Ese enfoque sigue siendo relevante en el contexto de esta nueva edición.
Otro cambio significativo en esta edición de la Guía del PMBOK® es una vista de sistemas del proyecto.
administración. Este cambio comienza con una visión de sistemas de la entrega de valor como parte de The
Standard for Project Management y continúa con la presentación del contenido de la Guía PMBOK® . Un enfoque de
sistemas para la entrega de valor cambia la perspectiva de gobernar carteras, programas y proyectos a centrarse en
la cadena de valor que vincula esas y otras capacidades comerciales para avanzar en la estrategia organizacional, el
valor y los objetivos comerciales. En el contexto de la gestión de proyectos, The Standard for Project Management y la
Guía PMBOK® enfatizan que los proyectos no solo producen productos, sino que, lo que es más importante, permiten
que esos productos impulsen resultados que, en última instancia, brindan valor a la organización y sus partes interesadas.

xi
Esta vista de sistemas refleja un cambio de las áreas de conocimiento en ediciones anteriores de la Guía PMBOK®
a ocho dominios de rendimiento del proyecto. Un dominio de desempeño es un grupo de actividades relacionadas que son
crítico para la entrega efectiva de los resultados del proyecto. Colectivamente, los dominios de desempeño representan
un sistema de gestión de proyectos de capacidades de gestión interactivas, interrelacionadas e interdependientes
que trabajan al unísono para lograr los resultados deseados del proyecto. A medida que los dominios de desempeño interactúan y reaccionan
entre sí, se produce el cambio. Los equipos de proyecto revisan, discuten, adaptan y responden continuamente a tales
cambios con todo el sistema en mente, no solo el dominio de rendimiento específico en el que el cambio
ocurrió. En línea con el concepto de un sistema para la entrega de valor en The Standard for Project Management, los equipos
evalúan el desempeño efectivo en cada dominio de desempeño a través de resultados centrados en
medidas, en lugar de a través de la adhesión a los procesos o la producción de artefactos, planes, etc.
Las ediciones anteriores de la Guía PMBOK® enfatizaron la importancia de adaptar el proyecto

enfoque de gestión a las características únicas de cada proyecto y su contexto. La sexta edición incorporó
específicamente consideraciones para ayudar a los equipos de proyectos a pensar en cómo adaptar su enfoque a la gestión
de proyectos. Ese contenido se incluyó en el material preliminar de cada una de las Áreas de conocimiento y proporcionó
consideraciones para todo tipo de entornos de proyecto. Esta edición amplía aún más ese trabajo con una sección dedicada
a la Sastrería en la Guía PMBOK® .
Una nueva sección sobre modelos, métodos y artefactos proporciona una agrupación de modelos de alto nivel,
métodos y artefactos que soportan la gestión de proyectos. Esta sección mantiene vínculos con herramientas,
técnicas y resultados de ediciones anteriores que respaldan la gestión de proyectos sin prescribir cuándo, cómo o qué
herramientas deben usar los equipos.
El cambio final refleja el avance más significativo en la historia de la Guía del PMBOK® :
la creación de PMIstandards+™, una plataforma digital interactiva que incorpora información actual, emergente y
y futuras prácticas, métodos, artefactos y otra información útil. El contenido digital mejor
refleja la naturaleza dinámica de un cuerpo de conocimiento. PMIstandards+ brinda a los profesionales de proyectos
y otras partes interesadas con acceso a una gama más rica y más amplia de información y recursos
que puedan adaptarse más rápidamente a los avances y cambios en la gestión de proyectos. El contenido
explica cómo se aplican prácticas, métodos o artefactos específicos a proyectos basados en segmentos de la industria,
tipos de proyectos u otras características. Comenzando con las entradas, herramientas y técnicas, y las salidas
de la Guía PMBOK® - Sexta edición, PMIstandards+ continuará incorporando nuevos recursos
que apoyan la evolución continua en la gestión de proyectos. En el futuro, los usuarios de The Standard
para la Gestión de Proyectos y la Guía del PMBOK® pueden encontrar información en PMIstandards+ que
complementar la información incluida en la publicación impresa.
La siguiente figura ilustra la revisión de The Standard for Project Management y la migración de la Sexta a
la Séptima Edición de la Guía del PMBOK® , junto con la conexión a la plataforma digital PMIstandards+.

xi
Guía del PMBOK® – Sexta edición Guía PMBOK® – Séptima edición
Una guía para la gestión de proyectos El Estándar para la Gestión de Proyectos: • Introducción
Cuerpo de conocimientos:
• Introducción, entorno del proyecto y función del • Sistema para la entrega de
Gerente de valor • Principios de gestión de
Proyecto • Áreas de proyectos • Administración •
Conocimiento • Personalización • Equipo • Partes
Calidad •
Integración • interesadas • Complejidad Riesgo
• Valor ••
Alcance • Pensamiento sistémico • Adaptabilidad
resiliencia • y
Cronograma • Costo Liderazgo • Cambio
• Calidad • Recursos
• Comunicaciones •
Riesgo • Adquisiciones
• Partes Interesadas Una guía para la gestión de proyectos
Cuerpo de conocimiento: •
Dominios de rendimiento del proyecto:
• Partes • Planificación
El estándar para la gestión de proyectos: interesadas • • Trabajo del
Equipo • Desarrollo proyecto •
• Inicio •
Acercamiento y Entrega • Medición
Planificación
• Ejecución • Ciclo de • Incertidumbre
Seguimiento y Control • Cierre vida • Adaptación

• Modelos, métodos y artefactos
Apéndices, glosario e índice Apéndices, glosario e índice
Plataforma de contenido digital PMIstandards+TM
• La plataforma se vincula a la Guía del PMBOK® a través de la sección Modelos, métodos y artefactos, al tiempo que amplía aún más ese contenido.
• La plataforma incorpora contenido de todos los estándares de PMI, así como contenido desarrollado específicamente para la plataforma. • El contenido
refleja “cómo…” en la práctica real, incluidas las prácticas emergentes.
Revisión del Estándar para la Gestión de Proyectos y la Migración de la Sexta Edición a la Séptima
Edición de la Guía PMBOK® y la Plataforma de Contenidos Digitales PMIstandards+TM
XIII
CONCLUSIÓN
El Estándar para la gestión de proyectos y la Guía del PMBOK® - Séptima edición responden a los cuatro elementos que las
partes interesadas han enfatizado en sus comentarios. La revisión mantiene y mejora la credibilidad y relevancia de la Guía
PMBOK® . Mejora la legibilidad y utilidad de la Guía del PMBOK® . Reconoce que existe un valor continuo para algunas partes
interesadas en la estructura y el contenido de las ediciones anteriores y mejora el contenido de esta edición sin negar ese valor.
Lo que es más importante, se vincula con la plataforma de contenido digital PMIstandards+ para responder a las necesidades de
las partes interesadas con contenido complementario examinado que respalda la aplicación práctica.

xiv
Tabla de contenido
EL ESTÁNDAR PARA LA GESTIÓN DE PROYECTOS
1. INTRODUCCIÓN ................................................ ..................................3 1.1 Propósito

de la Norma para la Gestión de Proyectos ....... ..............3 1.2 Términos y
conceptos clave ............................... ...............................4 1.3 Audiencia de esta
Norma .................. ..........................................5
2 UN SISTEMA PARA LA ENTREGA DE VALOR ........................................... ...........7

2.1 Creación de valor................................................... .............................7 2.1.1
Componentes de entrega de valor .................. ..........................8 2.1.2 Flujo
de información ............ ..........................................11
2.2 Sistemas de Gobierno Organizacional ................................................12 2.3
Funciones Asociadas a Proyectos ..........................................12 2.3.1 Proporcionar
supervisión y coordinación ...........................13 2.3.2 Presentar objetivos y
retroalimentación ........... ........................13 2.3.3 Facilitar y
apoyar ............................... ..........................14 2.3.4 Realizar trabajo y aportar
conocimientos ........ ...........14 2.3.5 Aplicar la
experiencia ........................... .....................................15 2.3.6 Proporcione
información y dirección comercial .... .......................15 2.3.7 Proporcionar
recursos y dirección .................. .................15
2.3.8 Mantener la Gobernanza.................................................... .........dieciséis
2.4 El entorno del proyecto ............................................... ............16 2.4.1 Entorno
interno .................................. ......................dieciséis
2.4.2 Entorno externo ............................................... ........18
2.5 Consideraciones sobre la gestión de productos ..........................18

XV
3 PRINCIPIOS DE LA GESTIÓN DE PROYECTOS ........................................... 21
3.1 Sea un administrador diligente, respetuoso y comprensivo ..................24 3.2 Cree un

entorno de equipo de proyecto colaborativo ...... ..........28 3.3 Involucrar efectivamente a las
partes interesadas .................................. ..31 3.4 Centrarse en el
valor........................................... .............................34
3.5 Reconocer, evaluar y responder a las interacciones del sistema .....37 3.6 Demostrar
conductas de liderazgo ................................ ..........40 3.7 Adaptar según el
contexto.................................... ........................44
3.8 Incorpore calidad en los procesos y entregables ........................47 3.9 Navegue por la
complejidad .................. .............................................50 3.10 Optimizar Respuestas al
riesgo .................................................. ........53 3.11 Adoptar la adaptabilidad y la
resiliencia .................................. ..55 3.12 Permitir el cambio para lograr el estado futuro
previsto .........58 Referencias ........................... .................................................... .........60
ÍNDICE .................................................. .................................................... 61

xvi
UNA GUÍA PARA LA GESTIÓN DE PROYECTOS

CUERPO DE CONOCIMIENTO ( GUÍA PMBOK®)
1. INTRODUCCIÓN ............................................... ....................................3

1.1 Estructura de la Guía del PMBOK® .................................................. ....3
1.2 Relación de la Guía del PMBOK® y El
Estándar para la Gestión de Proyectos..........................4 1.3 Cambios en el
PMBOK ® Guía .................................................. 6 1.4 Relación con los estándares
PMI+.................................................. ....6
2. DOMINIOS DE DESEMPEÑO DEL PROYECTO ........................................... ....7 2.1
Dominio de desempeño de las partes interesadas ............................... ...8 2.1.1
Participación de las partes interesadas ............................... ..... 10 2.1.2
Interacciones con otros dominios de rendimiento ......... 14
2.1.3 Comprobación de resultados ............................................. ..............15
2.2 Dominio del rendimiento del equipo.................... ........................dieciséis
2.2.1 Gestión y liderazgo del equipo del proyecto .................17 2.2.2 Cultura
del equipo del proyecto .................. .....................................20 2.2.3 Equipos
de proyecto de alto rendimiento .... ..........................22 2.2.4 Habilidades de
Liderazgo ........... .............................................23 2.2 .5 Estilos de Liderazgo a
la Medida..........................................30 2.2.6 Interacciones con otros dominios
de rendimiento ...........31
2.2.7 Comprobación de resultados ............................................. ...............31
2.3 Enfoque de desarrollo y dominio de rendimiento del ciclo de
vida........................... .....................................32
2.3.1 Relación de desarrollo, cadencia y ciclo de vida .....33 2.3.2 Cadencia
de entrega ........................... ..............................33 2.3.3 Enfoques de
desarrollo .............. ..............................35 2.3.4 Consideraciones para
seleccionar un enfoque de desarrollo ......... .....................................39 2.3.5
Definiciones de ciclo de vida y fase.... ..........................42 2.3.6
Alineación de la cadencia de entrega, el enfoque de desarrollo y el ciclo de
vida... ............................................46 2.3.7 Interacciones con Otros dominios
de rendimiento ........... 49
2.3.8 Medición de resultados ............................................... .......50

xvii
2.4 Dominio del rendimiento de la planificación ............................................... ...51

2.4.1 Descripción general de la planificación ............................... ...............52
2.4.2 Variables de planificación.................................. ............................53
2.4.3 Composición y estructura del equipo del
proyecto .................. ..........63 2.4.4 Comunicación .................................. ..................
2.4.5 Recursos físicos ............................................... ...........65 2.4.6
Adquisiciones ....................................... ...............................sesenta y cinco
2.4.7 Cambios .............................................. ..........................66 2.4.8
Métricas.................... .................................................... .....66
2.4.9 Alineación ............................................... ...............67 2.4.10
Interacciones con otros dominios de rendimiento ..................67 2.4.11
Comprobación de resultados .................................. ...........68 2.5
Dominio de desempeño del trabajo del proyecto ........................... .........69
2.5.1 Procesos del proyecto ............................... .......................71 2.5.2
Equilibrio de restricciones en competencia .................. ..............72
2.5.3 Mantener el enfoque del equipo del proyecto .................. ........73
2.5.4 Comunicaciones y participación en el proyecto .........73 2.5.5
Gestión de recursos físicos ....... ..................................73 2.5.6 Trabajar
con Adquisiciones ........... ..........................74 2.5.7 Monitoreo de
nuevos trabajos y cambios ......... .....................76 2.5.8 Aprendizaje a
lo largo del Proyecto .................. ...............77 2.5.9 Interacciones con
otros dominios de rendimiento ...............78
2.5.10 Comprobación de resultados ............................................. ...............79
2.6 Dominio del desempeño de la entrega ........................... ...........80 2.6.1
Entrega de valor ........................... ....................................81 2.6.2
Entregables .......... .................................................... ......82
2.6.3 Calidad .............................................. ............................87 2.6.4
Resultados subóptimos .................. ..........................91 2.6.5
Interacciones con otros dominios de rendimiento ...... ........91
2.6.6 Comprobación de resultados ............................................. ...............
92 2.7 Dominio del desempeño de la medición .................................. ...........93
2.7.1 Establecimiento de medidas efectivas ................................95
2.7.2 Qué medir . .................................................... .......98
2.7.3 Presentación de información ............................................. ..106

xviii
2.7.4 Errores de medición .................................................. ......111 2.7.5 Solución de
problemas de rendimiento ...........................113 2.7.6 Creciendo y

mejorando ............................................... ..114 2.7.7 Interacciones con otros
dominios de rendimiento ............114
2.7.8 Comprobación de resultados ............................................. ............115 2.8

Dominio de rendimiento de la incertidumbre ........................... ..........116 2.8.1
Incertidumbre general .................................. ...........119 2.8.2
Ambigüedad ........................... ..........................................120 2.8.3
Complejidad..... .................................................... ...........120 2.8.4
Volatilidad ........................................... ..........................122 2.8.5
Riesgo .......... .................................................... ..........122
2.8.6 Interacciones con otros dominios de rendimiento ..........128
2.8.7 Comprobación de resultados ............................................. ............129
3. SASTRERÍA ............................................................. ..........................................131

3.1 Descripción general ............................................. ...............................131
3.2 ¿Por qué personalizar? .................................................... ..........................133 3.3 Qué

personalizar .................. .................................................... ...134
3.3.1 Ciclo de vida y selección del enfoque de desarrollo ........134 3.3.2

Procesos ........................... ..........................................135
3.3.3 Compromiso.................................................... ....................136 3.3.4

Herramientas .......................... ..........................................136
3.3.5 Métodos y artefactos ............................................... ....136
3.4 El proceso de sastrería ............................................... ..........137 3.4.1 Seleccionar el

enfoque de desarrollo inicial ........................... 138 3.4.2 Adaptarse a la
organización ........................................... 139 3.4.3 Adaptarse al
proyecto ............................................... ..........141 3.5 Adaptación de los dominios
de rendimiento .................................. .....145 3.5.1 Partes
interesadas ........................................... .......................147
3.5.2 Equipo del proyecto ............................................. ...........147 3.5.3 Enfoque de

desarrollo y ciclo de vida ........................... .148 3.5.4
Planificación ........................................ ..........................148 3.5.5 Trabajo del
proyecto .................. .............................................149 3.5.6
Entrega .................................................... ....................149

xix
3.5.7 Incertidumbre ............................................... ...................150 3.5.8

Medición .......................... ....................................150
3.6 Diagnóstico................................................... .............................151 3.7

Resumen .................. .................................................... ............152
4. MODELOS, MÉTODOS Y ARTEFACTOS.................................................. .153 4.1 Descripción

general ............................................. ..........................153
4.2 Modelos de uso común ............................................... ...........155 4.2.1 Modelos de

Liderazgo Situacional .................................. ....155 4.2.2 Modelos de
comunicación ........................................... .......157 4.2.3 Modelos de
motivación .................................. ..........158
4.2.4 Modelos de cambio ............................................. ..............160 4.2.5 Modelos

de complejidad ............................... .......................164 4.2.6 Modelos de desarrollo
de equipos de proyecto .................. ..........166 4.2.7 Otros
modelos.................................... .............................168
4.3 Modelos aplicados a través de dominios de rendimiento ...........172 4.4 Métodos

comúnmente utilizados .................. ..........................................174 4.4.1 Recopilación y
análisis de datos ..... ....................................174 4.4.2
Estimación.......... .................................................... .......178 4.4.3 Reuniones y
Eventos.................................... ...............179 4.4.4 Otros
métodos ............................... .............................181
4.5 Métodos aplicados a través de los dominios de rendimiento ..........181 4.6 Artefactos
de uso común ............... .....................................184 4.6.1 Artefactos de
estrategia ....... ..........................................184 4.6 .2 Bitácoras y
Registros ............................................... .........185 4.6.3
Planos .................................. .......................................186 4.6.4 Gráficos de
jerarquía ..... .................................................... ..187 4.6.5 Líneas de

base ........................................... ..........................188
4.6.6 Información y datos visuales..........................................188
4.6.7 Informes .............................................. .......................190 4.6.8 Acuerdos y

Contratos .................. ........................191 4.6.9 Otros
artefactos.................... ..........................................192
4.7 Artefactos aplicados a través de dominios de desempeño .................192

Referencias ........................... .................................................... .............196

XX
APÉNDICE X1
COLABORADORES Y REVISORES DEL ESTÁNDAR
PARA LA DIRECCIÓN DE PROYECTOS Y UNA GUÍA PARA EL
CUERPO DE CONOCIMIENTOS PARA LA DIRECCIÓN DE PROYECTOS:
SÉPTIMA EDICIÓN .......... ....................197
X1.1 Colaboradores.................................................. .........................197 X1.2 Personal del
PMI .................. .................................................... .......206
APÉNDICE X2
PATROCINADOR ............................................... .............................................207
X2.1 Introducción .............................................. .........................207
X2.2 El papel del patrocinador ............................................. ...................207 X2.3 Falta de

Compromiso......................... ...................................208 X2.4 Comportamientos del
patrocinador ......... .................................................... ...209 X2.5
Conclusión................................................ ..........................210 X2.6 Recursos
sugeridos ............ .............................................210
APÉNDICE X3 LA
OFICINA DE GESTIÓN DE PROYECTOS........................................... ...211
X3.1 Introducción .............................................. .........................211
X3.2 La propuesta de valor de la PMO: ¿por qué tener una? ...................211 X3.3
Capacidades clave de la PMO .................. ..........................213 X3.4 Evolución para una
mayor realización de beneficios ......... ..........214 X3.5 Más información sobre las
PMO .......................... ..........................215
X3.6 Recursos sugeridos ............................................... ..........215
ANEXO X4
PRODUCTO.................................................... .............................................217
X4.1 Introducción .............................................. .........................217
X4.2 Cambios en el mercado global ............................................. ..............219
X4.3 Impacto en las prácticas de entrega de proyectos ..........................221 X4.4

Consideraciones organizacionales para el producto
Administración ................................................. ..221 X4.5
Resumen .................................................. ..........................225 X4.6 Recursos
sugeridos ........... .............................................225

xxx
APÉNDICE X5
INVESTIGACIÓN Y DESARROLLO DEL ESTÁNDAR
PARA LA GESTIÓN DE PROYECTOS ................................227
X5.1 Introducción .............................................. ..........................227 X5.2 El paso a un estándar
basado en principios ............... ...............227 X5.3 Investigación para el estándar para la

gestión de proyectos ..........228 X5.4 Proceso de desarrollo del estándar ....... ..........................229
X5.5 Validación del estándar ........ .............................................230X5.6
Resumen ................................................. ..........................232
GLOSARIO .................................................. .......................................233 1. Inclusiones y

Exclusiones... .................................................... .....233
2. Acrónimos comunes ............................................... ...........234 3.

Definiciones........................... .................................................... ....235
ÍNDICE .................................................. ..........................................255

XXII
Lista de Figuras y Tablas

Figura 2-1. Ejemplo de un Sistema para la Entrega de Valor ..........................9

Figura 2-2. Componentes de un sistema de muestra para la entrega de valor ......10
Figura 2-3. Ejemplo de Flujo de Información .......................................11
Figura 2-4. Muestra del ciclo de vida del producto ............................................. 19
Figura 3-1. Superposición de Gestión de Proyectos
y Principios Generales de Gestión ................................22
Figura 3-2. Sea un mayordomo diligente, respetuoso y comprensivo .................24
Figura 3-3. Crear un entorno de equipo de proyecto colaborativo ..........28
Figura 3-4. Involucrarse de manera efectiva con las partes interesadas .........31
Figura 3-5. Centrarse en el valor ............................................... ..........34
Figura 3-6. Reconocer, evaluar y responder a las
interacciones del sistema.................................... ...........37
Figura 3-7. Demostrar Comportamientos de Liderazgo ..........................40
Figura 3-8. Adaptar según el contexto .............................................. ...44
Figura 3-9. Incorporar la calidad en los procesos y entregables ..................47

Figura 3-10. Complejidad de navegación ............................................. ......50
Figura 3-11. Optimizar las respuestas al riesgo................................................. .53
Figura 3-12. Adopte la adaptabilidad y la resiliencia...................................55
Figura 3-13. Habilitar cambio para lograr
el estado futuro previsto ................................................58

XXIII
UNA GUÍA PARA LA GESTIÓN DE PROYECTOS

CUERPO DE CONOCIMIENTO ( GUÍA PMBOK®)
Figura 1-1. Relación entre los Principios de Gestión de

Proyectos y los Dominios de Desempeño de Proyectos .........5
Figura 2-1. Dominio de desempeño de las partes interesadas ...........8
Figura 2-2. Ejemplos de partes interesadas del proyecto ..........................9
Figura 2-3. Navegando por la participación efectiva de las partes interesadas ..........10
Figura 2-4. Dominio del rendimiento del equipo ....................................... 16
Figura 2-5. Componentes de la Inteligencia Emocional ..........................27
Figura 2-6. Enfoque de desarrollo y ciclo de vida
Dominio de rendimiento .................................................. ......32
Figura 2-7. Enfoques de desarrollo ................................................35
Figura 2-8. Desarrollo iterativo e incremental...................................37
Figura 2-9. Ejemplo de ciclo de vida predictivo .......................................43
Figura 2-10. Ciclo de Vida con un Enfoque de
Desarrollo Incremental........................................... .......44
Figura 2-11. Ciclo de Vida con Enfoque de Desarrollo Adaptativo ..........45
Figura 2-12. Ciclo de Vida del Centro Comunitario .......................................48
Figura 2-13. Dominio del desempeño de la planificación ................................51
Figura 2-14. El rango estimado disminuye con el tiempo ..........................56
Figura 2-15. Baja precisión, alta precisión ................................................56
Figura 2-16. Ejemplos de seguimiento rápido .............................................. ...60
Figura 2-17. Plan de lanzamiento e iteración ............................................... 61
Figura 2-18. Elaboración del presupuesto ............................................... ..............63
Figura 2-19. Dominio de desempeño del trabajo del proyecto ...............69
Figura 2-20. Dominio de rendimiento de entrega ................................80
Figura 2-21. Escenario para el desarrollo de un reloj inteligente .........86
Figura 2-22. Curva de Costo de Cambio .............................................. ......90
Figura 2-23. Dominio del rendimiento de la medición .......................... 93
Figura 2-24. Análisis del valor ganado que muestra la
variación del cronograma y el costo .................................. ...............101
Figura 2-25. Tablero de humor ................................................ ...............103
Figura 2-26. Pronóstico de Estimación al Finalizar
y Estimación para completar ....................................... 105

XXIV
Figura 2-27. Ejemplo de cuadro de mando................................................. ......107

Figura 2-28. Radiador de información ................................................ ....108
Figura 2-29. Tablero de Tareas o Tablero Kanban .......................................110
Figura 2-30. Gráfico de quemado ................................................ ..........111
Figura 2-31. Tasas de gastos planificados y reales .................................113
Figura 2-32. Dominio de desempeño de la incertidumbre ..........................116
Figura 2-33. Reducción del riesgo a lo largo del tiempo .......................................124
Figura 2-34. Curva de ROI ajustada al riesgo ............................................... 126
Figura 3-1. Detalles de los Pasos en el Proceso de Adaptación .................137
Figura 3-2. Selección del enfoque de desarrollo inicial ...........138
Figura 3-3. Adaptando el enfoque para la organización .................139
Figura 3-4. Evaluación de los factores organizativos y del proyecto al
adaptar.................................................. ....................140
Figura 3-5. Adaptación del enfoque para el proyecto ..........................143
Figura 3-6. Implementar la mejora continua ................................144
Figura 3-7. El proceso de confección .................................................. .....145
Figura 3-8. Adaptación para adaptarse al contexto del proyecto ..........................146
Figura 4-1. Adaptación para adaptarse al contexto
y entorno del proyecto ........................................... ..........154
Figura X4-1. Tendencias comerciales globales que influyen
la Gestión de Productos .......................................219
Figura X4-2. La relación cambiante entre
una organización y sus clientes...................................220
Figura X4-3. Estrategias de apoyo para continuo
Entrega de valor .................................................. ..............222
Tabla 2-1. Tipos de comunicación ............................................... ..13
Tabla 2-2. Comprobación de resultados: dominio
de desempeño de las partes interesadas .................................. ..........15
Tabla 2-3. Comprobación de resultados—Dominio de rendimiento del equipo ...........31
Tabla 2-4. Cadencia de entrega y enfoque de desarrollo ...........46
Tabla 2-5. Comprobación de resultados: enfoque de desarrollo
y dominio de rendimiento del ciclo de vida .......................... 50
Tabla 2-6. Comprobación de resultados:
dominio del rendimiento de la planificación .................................. ..........68

xiv

de rendimiento del trabajo del proyecto .................................. ...........79
Tabla 2-8. Comprobación de resultados—
Dominio del rendimiento de la entrega .................................. ..........92
del rendimiento de la medición .................................. ........115
Tabla 2-10. Comprobación de resultados: incertidumbre
Dominio de rendimiento .................................................. ....129
Tabla 3-1. Situaciones Comunes y Sugerencias de Adaptación...............151
Tabla 4-1. Mapeo de modelos que es probable que
se utilicen en cada dominio de desempeño .................................. .173
Tabla 4-2. Mapeo de métodos que probablemente se
usarán en cada dominio de desempeño .................................. .182
Tabla 4-3. Mapeo de artefactos que probablemente
se usarán en cada dominio de desempeño .................................. .193
Tabla X4-1. Vistas de Gestión de Proyectos y Productos ..................217
Tabla X4-2. Características únicas de los proyectos,
Programas y productos .................................................. .224

xxi
LA
ESTÁNDAR PARA
GESTIÓN DE PROYECTOS


1
Introducción
El Estándar para la Gestión de Proyectos identifica los principios de gestión de proyectos que guían los
comportamientos y las acciones de los profesionales de proyectos y otras partes interesadas que trabajan o están
comprometidas con los proyectos.
Esta sección introductoria describe el propósito de este estándar, define términos y conceptos clave e
identifica la audiencia del estándar.
El Estándar para la Gestión de Proyectos consta de las siguientes secciones:
ÿ Sección 1 Introducción
ÿ Sección 2 Un sistema para la entrega de valor
ÿ Sección 3 Principios de gestión de proyectos
1.1 PROPÓSITO DE LA NORMA PARA LA GESTIÓN DE PROYECTOS
El Estándar para la Gestión de Proyectos proporciona una base para comprender la gestión de proyectos y cómo
permite los resultados esperados. Este estándar se aplica independientemente de la industria, la ubicación, el tamaño o
el enfoque de entrega, por ejemplo, predictivo, híbrido o adaptativo. Describe el sistema dentro del cual operan los
proyectos, incluida la gobernanza, las posibles funciones, el entorno del proyecto y las consideraciones sobre la relación
entre la gestión de proyectos y la gestión de productos.

3
1.2 TÉRMINOS Y CONCEPTOS CLAVE
El Estándar para la Gestión de Proyectos refleja la progresión de la profesión. Organizaciones

esperar que los proyectos brinden resultados además de productos y artefactos. Se espera que los gerentes de proyecto
entreguen proyectos que creen valor para la organización y las partes interesadas dentro del sistema de entrega de valor
de la organización. Los siguientes términos se definen para proporcionar contexto para el contenido de este estándar.
ÿ Resultado. Un resultado final o consecuencia de un proceso o proyecto. Los resultados pueden incluir
productos y artefactos, pero tienen una intención más amplia al centrarse en los beneficios y el valor que el proyecto
se comprometió a entregar.
ÿ Portafolio. Proyectos, programas, carteras subsidiarias y operaciones gestionadas como grupo

para alcanzar los objetivos estratgicos.
ÿ Producto. Un artefacto que se produce, es cuantificable y puede ser un artículo final en sí mismo
o un elemento componente.
ÿ Programa. Proyectos relacionados, programas subsidiarios y actividades de programas que se administran de manera
coordinada para obtener beneficios que no están disponibles al administrarlos individualmente.
ÿ Proyecto. Un esfuerzo temporal emprendido para crear un producto, servicio o resultado único.
La naturaleza temporal de los proyectos indica un comienzo y un final del trabajo del proyecto o una fase del trabajo
del proyecto. Los proyectos pueden ser independientes o ser parte de un programa o cartera.
ÿ Gestión de proyectos. La aplicación de conocimientos, habilidades, herramientas y técnicas para

actividades del proyecto para cumplir con los requisitos del proyecto. La gestión de proyectos se refiere a guiar el
trabajo del proyecto para entregar los resultados previstos. Los equipos de proyecto pueden lograr los resultados
utilizando una amplia gama de enfoques (p. ej., predictivo, híbrido y adaptativo).
ÿ Jefe de proyecto. La persona asignada por la organización ejecutora para liderar el equipo del proyecto que es
responsable de lograr los objetivos del proyecto. Los gerentes de proyecto realizan una variedad de funciones, como
facilitar el trabajo del equipo del proyecto para lograr los resultados y administrar los procesos para entregar los
resultados esperados. Las funciones adicionales se identifican en la Sección 2.3.

4 El estándar para la gestión de proyectos
ÿ Equipo de proyecto. Un conjunto de individuos que realizan el trabajo del proyecto para lograr
sus objetivos
ÿ Sistema de entrega de valor. Una colección de actividades comerciales estratégicas destinadas a construir,
sostener y/o hacer avanzar una organización. Las carteras, los programas, los proyectos, los productos y las
operaciones pueden formar parte del sistema de entrega de valor de una organización.
ÿ Valor. Valor, importancia o utilidad de algo. Diferentes partes interesadas perciben el valor de diferentes maneras.
Los clientes pueden definir el valor como la capacidad de usar características o funciones específicas de un
producto. Las organizaciones pueden centrarse en el valor comercial determinado con métricas financieras, como
los beneficios menos el costo de lograr esos beneficios. El valor social puede incluir la contribución a grupos de
personas, comunidades o el medio ambiente.
Para conocer otros términos utilizados en este estándar, consulte el Glosario y el Léxico de términos de
gestión de proyectos del PMI [1].1
1.3 AUDIENCIA PARA ESTE ESTÁNDAR
Este estándar proporciona una referencia fundamental para las partes interesadas que participan en un proyecto.
Esto incluye, entre otros, profesionales del proyecto, consultores, educadores, estudiantes, patrocinadores, partes
interesadas y proveedores que:
ÿ Son responsables de entregar los resultados del proyecto;
ÿ Trabajar en proyectos a tiempo completo o parcial;
ÿ Trabajar en oficinas de gestión de carteras, programas o proyectos (PMO);
ÿ Están involucrados en el patrocinio de proyectos, propiedad de productos, gestión de productos,

liderazgo ejecutivo o gobierno de proyectos;
ÿ Están involucrados en la gestión de carteras o programas;
ÿ Proporcionar recursos para el trabajo del proyecto;
ÿ Centrarse en la entrega de valor para carteras, programas y proyectos;
ÿ Enseñar o estudiar gestión de proyectos; y
ÿ Están involucrados en cualquier aspecto de la cadena de entrega de valor del proyecto.
1 Los números entre paréntesis se refieren a la lista de referencias al final de esta norma.

Sección 1 Introducción 5

2
Un sistema para la entrega de valor
La información de esta sección proporciona un contexto para la entrega de valor, la gobernanza, el proyecto
funciones, el entorno del proyecto y la gestión del producto.
ÿ Sección 2.1 Creación de valor. Esta sección describe cómo funcionan los proyectos dentro de un sistema.
para producir valor para las organizaciones y sus grupos de interés.
ÿ Sección 2.2 Sistemas de Gobierno Organizacional. Esta sección describe cómo la gobernanza
apoya un sistema para la entrega de valor.
ÿ Sección 2.3 Funciones Asociadas a Proyectos. Esta sección identifica las funciones
que apoyan proyectos.
ÿ Sección 2.4 El entorno del proyecto. En esta sección se identifican internos y externos.
factores que influyen en los proyectos y la entrega de valor.
ÿ Sección 2.5 Consideraciones sobre la gestión de productos. Esta sección identifica las formas
se relacionan portafolios, programas, proyectos y productos.
2.1 CREACIÓN DE VALOR
Los proyectos existen dentro de un sistema más grande, como una agencia gubernamental, organización o
arreglo. En aras de la brevedad, esta norma utiliza el término organización cuando se refiere a agencias gubernamentales,
empresas, arreglos contractuales, empresas conjuntas y otros arreglos.
Las organizaciones crean valor para las partes interesadas. Los ejemplos de formas en que los proyectos producen valor
incluyen, pero no se limitan a:

Sección 2: un sistema para la entrega de valor 7
ÿ Crear un nuevo producto, servicio o resultado que satisfaga las necesidades de los clientes o usuarios finales;
ÿ Crear contribuciones sociales o ambientales positivas;
ÿ Mejorar la eficiencia, la productividad, la eficacia o la capacidad de respuesta;
ÿ Permitir los cambios necesarios para facilitar la transición organizacional hacia el futuro deseado
Expresar; y
ÿ Mantener los beneficios habilitados por programas, proyectos u operaciones comerciales anteriores.
2.1.1 COMPONENTES DE ENTREGA DE VALOR
Hay varios componentes, como carteras, programas, proyectos, productos y operaciones, que se
pueden utilizar de forma individual y colectiva para crear valor. Trabajando juntos, estos componentes comprenden
un sistema para entregar valor que está alineado con la estrategia de la organización.
La figura 2-1 muestra un ejemplo de un sistema para entregar valor que tiene dos carteras compuestas por
programas y proyectos. También muestra un programa independiente con proyectos y proyectos independientes no
asociados con carteras o programas. Cualquiera de los proyectos o programas podría incluir productos.
Las operaciones pueden respaldar e influir directamente en carteras, programas y proyectos, así como en otras
funciones comerciales, como la nómina, la gestión de la cadena de suministro, etc. Las carteras, los programas y
los proyectos se influyen entre sí, así como también en las operaciones.

Sistema de Entrega de Valor
Portafolio A Cartera B Programa N.1
Programa A.1 Programa A.2 Programa B.1 Proyectos
Proyectos Proyectos
Proyectos Proyectos
Operaciones
Figura 2-1. Ejemplo de un sistema para la entrega de valor
Como se muestra en la Figura 2-2, un sistema para la entrega de valor es parte del
entorno interno de una organización que está sujeto a políticas, procedimientos, metodologías,
marcos, estructuras de gobierno, etc. Ese entorno interno existe dentro del entorno externo más
amplio, que incluye la economía, el entorno competitivo, las restricciones legislativas, etc. La
Sección 2.4 brinda más detalles sobre los entornos interno y externo.

Ambiente externo
Ambiente interno
Sistema de Entrega de Valor
Portafolio A Cartera B
Programa N.1
Programa A.1 Programa A.2 Programa B.1 Proyectos
Proyectos Proyectos
Proyectos Proyectos
Operaciones
Figura 2-2. Componentes de un sistema de muestra para la entrega de valor
Los componentes de un sistema de entrega de valor crean entregables que se utilizan para producir resultados. Un resultado
es el resultado final o la consecuencia de un proceso o proyecto. Centrarse en los resultados, las opciones y las decisiones enfatiza
el desempeño a largo plazo del proyecto. Los resultados crean beneficios, que son ganancias realizadas por la organización. Los
beneficios, a su vez, crean valor, que es algo valioso, importante o útil.

2.1.2 FLUJO DE INFORMACIÓN
Un sistema de entrega de valor funciona de manera más efectiva cuando se comparten información y comentarios.
consistentemente entre todos los componentes, manteniendo el sistema alineado con la estrategia y en sintonía con
el entorno.
La Figura 2-3 muestra un modelo del flujo de información donde las flechas negras representan información
desde el liderazgo senior hasta las carteras, las carteras hasta los programas y proyectos, y luego hasta las operaciones.
El liderazgo sénior comparte información estratégica con las carteras. Los portafolios comparten los resultados deseados, los
beneficios y el valor con los programas y proyectos. Los entregables de programas y proyectos se pasan a operaciones junto
con información sobre soporte y mantenimiento para los entregables.
Las flechas de color gris claro en la Figura 2-3 representan el flujo inverso de información. La información de las
operaciones a los programas y proyectos sugiere ajustes, correcciones y actualizaciones a los entregables.
Los programas y proyectos brindan información sobre el desempeño y el progreso en el logro de los resultados, beneficios
y valor deseados para las carteras. Las carteras proporcionan evaluaciones sobre el desempeño de la cartera con el liderazgo
senior. Además, las operaciones brindan información sobre qué tan bien está avanzando la estrategia de la organización.
Resultados deseados, Entregables con soporte

Estrategia beneficios y valor e información de mantenimiento
Sénior Programas
Portafolios Operaciones
Liderazgo y Proyectos
Rendimiento de la cartera Información de rendimiento Información para actualizaciones,

información y progreso arreglos y ajustes
Resultados, beneficios, análisis de rendimiento de valor
Figura 2-3. Ejemplo de flujo de información

2.2 SISTEMAS DE GOBIERNO ORGANIZACIONAL

El sistema de gobierno funciona junto con el sistema de entrega de valor para permitir flujos de trabajo fluidos,
gestionar problemas y apoyar la toma de decisiones. Los sistemas de gobernanza proporcionan un marco con funciones
y procesos que guían las actividades. Un marco de gobernanza puede incluir elementos de supervisión, control,
evaluación de valor, integración entre componentes y capacidad de toma de decisiones.
Los sistemas de gobierno proporcionan una estructura integrada para evaluar cambios, problemas y riesgos
asociado con el medio ambiente y cualquier componente en el sistema de entrega de valor. Esto incluye los objetivos de la
cartera, los beneficios del programa y los entregables producidos por los proyectos.
Los proyectos pueden operar dentro de un programa o cartera o como una actividad independiente. En algunos
organizaciones, una oficina de gestión de proyectos podría apoyar programas y proyectos dentro de un
portafolio. El gobierno del proyecto incluye definir la autoridad para aprobar cambios y hacer otros
decisiones comerciales relacionadas con el proyecto. La gobernanza del proyecto está alineada con el programa y/o
gobierno organizacional.
2.3 FUNCIONES ASOCIADAS A PROYECTOS

Las personas impulsan la entrega del proyecto. Lo hacen cumpliendo las funciones necesarias para que el proyecto se
ejecute de manera efectiva y eficiente. Las funciones relacionadas con el proyecto pueden ser realizadas por una persona, por
un grupo de personas o combinadas en roles definidos.
Coordinar un esfuerzo de trabajo colectivo es extremadamente importante para el éxito de cualquier proyecto.
Hay diferentes tipos de coordinación adecuados para diferentes contextos. Algunos proyectos se benefician de la coordinación
descentralizada en la que los miembros del equipo del proyecto se organizan y gestionan por sí mismos. Otros proyectos se
benefician de la coordinación centralizada con el liderazgo y la orientación de un director de proyecto designado o una función
similar. Algunos proyectos con coordinación centralizada también pueden beneficiarse de la inclusión de equipos de proyecto
autoorganizados para partes del trabajo. Independientemente de cómo se lleve a cabo la coordinación, los modelos de liderazgo
de apoyo y los compromisos significativos y continuos entre los equipos del proyecto y otras partes interesadas sustentan los
resultados exitosos.

Independientemente de cómo se coordinen los proyectos, el esfuerzo colectivo del equipo del proyecto genera
resultados, beneficios y valor. El equipo del proyecto puede estar respaldado por funciones adicionales según los entregables,
la industria, la organización y otras variables. Las secciones 2.3.1 a 2.3.8 brindan ejemplos de funciones que a menudo se
encuentran en los proyectos, aunque no son una lista exhaustiva.
Además de estas funciones, pueden ser necesarias otras funciones para habilitar los entregables del proyecto que
produzcan los resultados deseados. Las necesidades del proyecto, la organización y el entorno influyen en qué funciones
se utilizan en un proyecto y cómo se llevan a cabo esas funciones.
2.3.1 PROPORCIONAR SUPERVISIÓN Y COORDINACIÓN
Las personas en esta función ayudan al equipo del proyecto a lograr los objetivos del proyecto, normalmente
orquestando el trabajo del proyecto. Los detalles de cómo se lleva a cabo esta función dentro del equipo del proyecto
pueden variar entre organizaciones, pero pueden incluir liderar las actividades de planificación, seguimiento y control. En
algunas organizaciones, esta función puede implicar algunas actividades de evaluación y análisis como parte de las
actividades previas al proyecto. Esta función incluye monitorear y trabajar para mejorar la salud, la seguridad y el bienestar
general de los miembros del equipo del proyecto.
La coordinación incluye consultar con los líderes ejecutivos y de unidades de negocios sobre ideas para avanzar en
los objetivos, mejorar el desempeño del proyecto o satisfacer las necesidades del cliente. También puede incluir la asistencia
en análisis de negocios, licitaciones y negociaciones de contratos, y desarrollo de casos de negocios.
La supervisión puede estar involucrada en actividades de seguimiento relacionadas con la realización y el

mantenimiento de los beneficios después de que se finalicen los entregables del proyecto pero antes del cierre formal del
proyecto. Esta función puede soportar carteras y programas dentro de los cuales se inicia el proyecto. En última instancia, la
función se adapta a la organización.
2.3.2 OBJETIVOS PRESENTES Y RETROALIMENTACIÓN
Las personas en esta función aportan perspectivas, conocimientos y una dirección clara de los clientes y usuarios
finales. El cliente y el usuario final no siempre son sinónimos. A los efectos de esta norma, el cliente se define como el
individuo o grupo que ha solicitado o está financiando el proyecto. El usuario final es el individuo o grupo que experimentará
el uso directo del entregable del proyecto.

Los proyectos necesitan una dirección clara de los clientes y usuarios finales con respecto a los requisitos del proyecto,
resultados y expectativas. En entornos de proyectos adaptables e híbridos, la necesidad de comentarios continuos es mayor
porque los equipos de proyecto están explorando y desarrollando elementos de productos dentro de incrementos específicos. En
algunos entornos de proyectos, el cliente o el usuario final interactúa con el equipo del proyecto para realizar revisiones y
comentarios periódicos. En algunos proyectos, un representante del cliente o del cliente participa en el equipo del proyecto. Las
necesidades de información y retroalimentación del cliente y del usuario final están determinadas por la naturaleza del proyecto y
la guía o dirección requerida.
2.3.3 FACILITAR Y APOYAR

La función de facilitación y apoyo puede estar estrechamente relacionada con la supervisión y coordinación, según
la naturaleza del proyecto. El trabajo implica alentar la participación, colaboración y un sentido compartido de responsabilidad
de los miembros del equipo del proyecto por el resultado del trabajo.
La facilitación ayuda al equipo del proyecto a crear consenso en torno a soluciones, resolver conflictos y tomar decisiones. La
facilitación también es necesaria para coordinar reuniones y contribuir de manera imparcial al avance de los objetivos del
proyecto.
También se requiere apoyar a las personas a través del cambio y ayudar a abordar los obstáculos que pueden impedir
el éxito. Esto puede incluir evaluar el desempeño y proporcionar comentarios a las personas y equipos de proyectos para
ayudarlos a aprender, adaptarse y mejorar.
2.3.4 REALIZAR TRABAJO Y APORTAR PERSPECTIVAS

Este grupo de personas proporciona el conocimiento, las habilidades y la experiencia necesarios para producir los
productos y obtener los resultados del proyecto. El trabajo puede ser a tiempo completo o a tiempo parcial durante la duración
del proyecto o por un período limitado, y el trabajo puede ser colocado o virtual, según los factores ambientales. Algunos trabajos
pueden ser altamente especializados, mientras que otros trabajos pueden ser realizados por miembros del equipo del proyecto
que tengan un amplio conjunto de habilidades.
Obtener información de los miembros del equipo del proyecto multifuncional que representan diferentes partes de
la organización puede proporcionar una combinación de perspectivas internas, establecer alianzas con unidades comerciales
clave y alentar a los miembros del equipo del proyecto a actuar como agentes de cambio dentro de sus áreas funcionales.
Este trabajo puede extenderse a funciones de soporte (durante o después del proyecto) a medida que los entregables del
proyecto se implementan o pasan a operaciones.

2.3.5 APLICAR LA EXPERIENCIA
Las personas en esta función brindan el conocimiento, la visión y la experiencia en un tema específico para un
proyecto. Ofrecen asesoramiento y apoyo en toda la organización y contribuyen al proceso de aprendizaje y precisión
del trabajo del equipo del proyecto. Estas personas pueden ser externas a la organización o pueden ser miembros
internos del equipo del proyecto. Pueden ser necesarios para todo el proyecto o durante un período de tiempo específico.
2.3.6 PROPORCIONAR DIRECCIÓN Y PERSPECTIVA EMPRESARIAL
Las personas en esta función guían y aclaran la dirección del resultado del proyecto o producto.
Esta función consiste en priorizar los requisitos o elementos del backlog en función del valor comercial, las
dependencias y el riesgo técnico u operativo. Las personas en esta función brindan retroalimentación a los equipos de
proyecto y establecen la dirección para el próximo incremento o elemento que se desarrollará o entregará. La función
implica interactuar con otras partes interesadas, clientes y sus equipos de proyecto para definir la dirección del producto.
El objetivo es maximizar el valor del entregable del proyecto.
En entornos adaptables e híbridos, la dirección y la percepción se pueden proporcionar utilizando una cadencia
específica. En entornos predictivos, se pueden designar puntos de control para la presentación y retroalimentación
sobre el progreso del proyecto. En algunos casos, la dirección empresarial puede interactuar con las funciones de
financiación y recursos.
2.3.7 PROPORCIONAR RECURSOS Y DIRECCIÓN
Las personas en esta función promueven el proyecto y comunican la visión, metas,

y expectativas para el equipo del proyecto y la comunidad más amplia de partes interesadas. Abogan por el proyecto
y el equipo del proyecto ayudando a asegurar las decisiones, los recursos y la autoridad que permiten que las actividades
del proyecto progresen.
Las personas en esta función sirven como enlaces entre la alta dirección y el equipo del proyecto,
desempeñar un papel de apoyo para mantener los proyectos alineados con los objetivos comerciales, eliminar
obstáculos y abordar problemas fuera de los límites de la autoridad de decisión del equipo del proyecto. Las personas
en esta función brindan una ruta de escalada para problemas, problemas o riesgos que los equipos de proyecto no pueden
resolver o administrar por sí mismos, como la escasez de fondos u otros recursos, o los plazos que no se pueden cumplir.

Esta función puede facilitar la innovación al identificar las oportunidades que surgen dentro del proyecto.
y comunicándolos a la alta dirección. Las personas en esta función pueden monitorear los resultados del proyecto
después del cierre del proyecto para garantizar que se obtengan los beneficios comerciales previstos.
2.3.8 MANTENER LA GOBERNANZA

Las personas que cumplen una función de gobierno aprueban y respaldan las recomendaciones realizadas
por el equipo del proyecto y supervisan el progreso del proyecto para lograr los resultados deseados. Mantienen
vínculos entre los equipos del proyecto y los objetivos estratégicos o comerciales que pueden cambiar a lo largo del
proyecto.
2.4 EL ENTORNO DEL PROYECTO

Los proyectos existen y operan dentro de entornos internos y externos que tienen diversos grados de influencia en
la entrega de valor. Los entornos internos y externos pueden influir en la planificación y otras actividades del proyecto.
Estas influencias pueden generar un impacto favorable, desfavorable o neutral en las características del proyecto, las
partes interesadas o los equipos del proyecto.
2.4.1 MEDIO AMBIENTE INTERNO

Los factores internos de la organización pueden surgir de la propia organización, una cartera, un
programa, otro proyecto o una combinación de estos. Incluyen artefactos, prácticas o conocimiento interno. El
conocimiento incluye lecciones aprendidas, así como artefactos completados de proyectos anteriores. Los ejemplos
incluyen pero no se limitan a:

dieciséis
El estándar para la gestión de proyectos
ÿ Procesar activos. Los activos del proceso pueden incluir herramientas, metodologías, enfoques, plantillas, marcos,
patrones o recursos de PMO.
ÿ Documentación de gobernanza. Esta documentación incluye políticas y procesos.
ÿ Activos de datos. Los activos de datos pueden incluir bases de datos, bibliotecas de documentos, métricas, datos y
artefactos de proyectos anteriores.
ÿ Activos de conocimiento. Los activos de conocimiento pueden incluir conocimiento tácito entre los miembros del
equipo del proyecto, expertos en la materia y otros empleados.
ÿ Seguridad y protección. Las medidas de seguridad y protección pueden incluir procedimientos y prácticas para el
acceso a las instalaciones, la protección de datos, los niveles de confidencialidad y los secretos de propiedad.
ÿ Cultura organizacional, estructura y gobierno. Estos aspectos de una organización incluyen la visión, misión, valores,
creencias, normas culturales, estilo de liderazgo, jerarquía y relaciones de autoridad, estilo organizacional, ética y
código de conducta.
ÿ Distribución geográfica de instalaciones y recursos. Estos recursos incluyen trabajo

ubicaciones, equipos de proyectos virtuales y sistemas compartidos.
ÿ Infraestructura. La infraestructura consiste en las instalaciones existentes, el equipo, los canales organizativos y de
telecomunicaciones, el hardware de tecnología de la información, la disponibilidad y la capacidad.
ÿ Software de tecnología de la información. Los ejemplos incluyen software de programación, sistemas de gestión de
configuración, interfaces web para sistemas automatizados en línea, herramientas de colaboración y sistemas de
autorización de trabajo.
ÿ Disponibilidad de recursos. Los ejemplos incluyen restricciones de contratación y compra, proveedores y subcontratistas
aprobados y acuerdos de colaboración. La disponibilidad relacionada con personas y materiales incluye restricciones
de contratación y compra, proveedores y subcontratistas aprobados y plazos.
ÿ Capacidad de los empleados. Los ejemplos incluyen experiencia general y especializada, habilidades,
competencias, técnicas y conocimientos.

2.4.2 MEDIO AMBIENTE EXTERNO

Los factores externos a la organización pueden mejorar, restringir o tener una influencia neutral en los resultados
del proyecto. Los ejemplos incluyen pero no se limitan a:
ÿ Condiciones del mercado. Las condiciones del mercado incluyen competidores, cuota de mercado,
reconocimiento de marca, tendencias tecnológicas y marcas registradas.
ÿ Influencias y problemas sociales y culturales. Estos factores incluyen el clima político, las costumbres y
tradiciones regionales, los días festivos y eventos, los códigos de conducta, la ética y las percepciones.
ÿ Entorno regulatorio. El entorno normativo puede incluir leyes y reglamentos nacionales y regionales relacionados con
la seguridad, la protección de datos, la conducta empresarial, el empleo, la concesión de licencias y la contratación.
ÿ Bases de datos comerciales. Las bases de datos incluyen datos de estimación de costos estandarizados y
información del estudio de riesgo de la industria.
ÿ Investigación académica. Esta investigación puede incluir estudios de la industria, publicaciones y

resultados de evaluación comparativa.
ÿ Estándares de la industria. Estos estándares están relacionados con los productos, la producción, el medio
ambiente, la calidad y la mano de obra.
ÿ Consideraciones financieras. Estas consideraciones incluyen tipos de cambio de moneda,

tasas de interés, inflación, impuestos y aranceles.
ÿ Entorno físico. El entorno físico se refiere a las condiciones de trabajo.

y el clima
2.5 CONSIDERACIONES SOBRE LA GESTIÓN DEL PRODUCTO
Las disciplinas de gestión de carteras, programas, proyectos y productos son cada vez más
interconectados. Si bien la gestión de carteras, programas y productos está más allá del alcance de este estándar, la
comprensión de cada disciplina y las relaciones entre ellas proporciona un contexto útil para los proyectos cuyos
entregables son productos.

Un producto es un artefacto que se produce, es cuantificable y puede ser un artículo final en sí mismo o un
artículo componente. La gestión de productos implica la integración de personas, datos, procesos y sistemas
comerciales para crear, mantener y desarrollar un producto o servicio a lo largo de su ciclo de vida. El ciclo de vida
del producto es una serie de fases que representa la evolución de un producto, desde la introducción hasta el
crecimiento, la madurez y el retiro.
La gestión de productos puede iniciar programas o proyectos en cualquier punto del ciclo de vida del producto
para crear o mejorar componentes, funciones o capacidades específicas (consulte la figura 2-4). El producto inicial
puede comenzar como un entregable de un programa o proyecto. A lo largo de su ciclo de vida, un nuevo programa
o proyecto puede agregar o mejorar componentes, atributos o capacidades específicos que crean valor adicional para
los clientes y la organización patrocinadora. En algunos casos, un programa puede abarcar el ciclo de vida completo
de un producto o servicio para administrar los beneficios y crear valor para la organización de manera más directa.
Gobernanza de la cartera
Programa A Programa B
Proyecto 3
Proyecto 4
(Adiciones)
(Revisiones)
Proyecto 5
(Revisiones)
Proyecto 2
(Más características) Proyecto 6
(Revisiones)
Proyecto 1
(Creación inicial) Proyecto 7
(Jubilación)
Tiempo
Producto
Ciclo vital Introducción Crecimiento Madurez Rechazo/Retiro
Etapas:
Figura 2-4. Ejemplo de ciclo de vida del producto

La gestión de productos puede existir en diferentes formas, incluidas, entre otras, las siguientes:
ÿ Gestión de programas dentro del ciclo de vida de un producto. Este enfoque incorpora
proyectos, programas subsidiarios y actividades del programa. Para muy grandes o de larga duración
productos, una o más fases del ciclo de vida del producto pueden ser lo suficientemente complejas como para merecer un conjunto
de programas y proyectos trabajando juntos.
ÿ Gestión de proyectos dentro del ciclo de vida de un producto. Este enfoque supervisa el desarrollo
y la maduración de las capacidades del producto como una actividad comercial continua. Gobernanza de la cartera
fleta proyectos individuales según sea necesario para realizar mejoras y mejoras o para
producir otros resultados únicos.
ÿ Gestión de productos dentro de un programa. Este enfoque aplica el ciclo de vida completo del producto.
dentro del alcance y los límites de un programa determinado. Una serie de programas subsidiarios
o se contratarán proyectos para lograr beneficios específicos para un producto. Esos beneficios pueden
mejorarse mediante la aplicación de competencias de gestión de productos como el análisis competitivo,
adquisición de clientes y defensa del cliente.
Si bien la gestión de productos es una disciplina separada con su propio cuerpo de conocimientos,
representa un punto clave de integración dentro de las disciplinas de gestión de programas y gestión de proyectos. Los
programas y proyectos con entregables que incluyen productos utilizan un enfoque personalizado e integrado que
incorpora todos los cuerpos de conocimiento relevantes y sus prácticas, métodos y artefactos relacionados.

3
Gestión de proyectos
Principios
Los principios de una profesión sirven como pautas fundamentales para la estrategia, la toma de decisiones y la
resolución de problemas. Los estándares y metodologías profesionales a menudo se basan en principios. En algunas
profesiones, los principios sirven como leyes o reglas y, por lo tanto, son de naturaleza prescriptiva. Los principios de la gestión
de proyectos no son de naturaleza prescriptiva. Están destinados a guiar el comportamiento de las personas involucradas en los
proyectos. Tienen una base amplia, por lo que hay muchas formas en que las personas y las organizaciones pueden mantener
la alineación con los principios.
Los principios pueden, pero no necesariamente, reflejar la moral. Un código de ética está relacionado con la moral.
Un código de ética para una profesión puede ser adoptado por un individuo o profesión para establecer expectativas
de conducta moral. El Código de Ética y Conducta Profesional de PMI [2] se basa en cuatro valores que se identificaron
como los más importantes para la comunidad de gestión de proyectos:
ÿ Responsabilidad,
ÿ Respeto,
ÿ Equidad, y
ÿ Honestidad.
Los 12 principios de la gestión de proyectos están alineados con los valores identificados en el Código de Ética y
Conducta Profesional de PMI. No siguen el mismo formato, ni se duplican, sino que los principios y el Código de Ética son
complementarios.
Los principios de la gestión de proyectos se identificaron y desarrollaron mediante la participación de un

comunidad de practicantes de proyectos. Los profesionales representan diferentes industrias, trasfondos culturales y
organizaciones en diferentes roles y con experiencia en varios tipos de proyectos.
Múltiples rondas de comentarios dieron como resultado 12 principios que brindan orientación para la gestión eficaz de
proyectos.
Sección 3 - Principios de gestión de proyectos 21

Debido a que los principios de la gestión de proyectos brindan orientación, el grado de aplicación y la forma
en que se aplican están influenciados por el contexto de la organización, el proyecto, los entregables, el equipo del
proyecto, las partes interesadas y otros factores. Los principios son internamente consistentes, lo que significa que
ningún principio contradice ningún otro principio. Sin embargo, en la práctica puede haber ocasiones en que los
principios se superpongan. Por ejemplo, la guía para navegar por la complejidad puede presentar información útil para
reconocer, evaluar y responder a las interacciones del sistema u optimizar las respuestas al riesgo.
Los principios de la gestión de proyectos también pueden tener áreas de superposición con la gestión general
principios Por ejemplo, tanto los proyectos como los negocios en general se enfocan en entregar valor. Los
métodos pueden ser algo diferentes en los proyectos en comparación con las operaciones, pero el principio
subyacente asociado con el enfoque en el valor puede aplicarse a ambos. La figura 3-1 demuestra esta superposición.
Proyecto General
administración administración
Principios Principios
Figura 3-1. Superposición de la gestión de proyectos y los principios generales de gestión

Las principales etiquetas se enumeran aquí sin ninguna ponderación u orden específico. Las
declaraciones de principios se presentan y describen en las Secciones 3.1 a 3.12. Cada sección comienza
con una figura que proporciona la etiqueta principal en la parte superior con el principio y los puntos clave
debajo de la etiqueta. Siguiendo la figura, cada principio se desarrolla en el texto. Las etiquetas principales son:
ÿ Sea un administrador diligente, respetuoso y solidario (consulte la Sección 3.1).
ÿ Cree un entorno de equipo de proyecto colaborativo (consulte la Sección 3.2).
ÿ Comprometerse de manera efectiva con las partes interesadas (consulte la Sección 3.3).
ÿ Centrarse en el valor (ver Sección 3.4).
ÿ Reconocer, evaluar y responder a las interacciones del sistema (consulte la Sección 3.5).
ÿ Demostrar comportamientos de liderazgo (consulte la Sección 3.6).
ÿ Adaptar según el contexto (ver Sección 3.7).
ÿ Incorpore calidad en los procesos y entregables (consulte la Sección 3.8).
ÿ Complejidad de navegación (consulte la Sección 3.9).
ÿ Optimizar las respuestas al riesgo (ver Sección 3.10).
ÿ Adoptar la adaptabilidad y la resiliencia (consulte la Sección 3.11).
ÿ Habilite el cambio para lograr el estado futuro previsto (consulte la Sección 3.12).

3.1 SEA UN MAYORDOMO DILIGENTE, RESPETUOSO Y CARIÑOSO
ADMINISTRACIÓN
Los delegados actúan de La administración abarca responsabilidades dentro y fuera de

manera responsable para llevar la organización.
a cabo actividades con La mayordomía incluye:
integridad, cuidado y
• Integridad,
confiabilidad mientras • Atención,
mantienen el cumplimiento de
• Confiabilidad, y
las pautas internas y externas. • Cumplimiento.
Demuestran un amplio
Una visión holística de la mayordomía considera los aspectos financieros, sociales,
compromiso con los aspectos financieros, sociales,
conciencia técnica y medioambiental sostenible.
e impactos ambientales
de los proyectos que apoyan.
Figura 3-2. Sea un mayordomo diligente, respetuoso y solidario

La mayordomía tiene significados y aplicaciones ligeramente diferentes en diferentes contextos. Un aspecto de

la mayordomía implica que se nos confíe el cuidado de algo. Otro aspecto se centra en la planificación, uso y gestión
responsable de los recursos. Otro aspecto más significa defender
valores y ética.
La administración abarca responsabilidades tanto dentro como fuera de la organización. Dentro de la organización,
la administración incluye:
ÿ Operar en alineación con la organización, sus objetivos, estrategia, visión, misión,

y mantenimiento de su valor a largo plazo;
ÿ Compromiso y participación respetuosa de los miembros del equipo del proyecto, incluidos sus
compensación, acceso a oportunidades y trato justo;
ÿ Supervisión diligente de las finanzas, los materiales y otros recursos de la organización utilizados
un proyecto; y
ÿ Comprender el uso apropiado de la autoridad, la rendición de cuentas y la responsabilidad,

particularmente en posiciones de liderazgo.
La administración fuera de la organización incluye responsabilidades en áreas tales como:
ÿ Sostenibilidad ambiental y uso de materiales y recursos naturales por parte de la organización;
ÿ la relación de la organización con las partes interesadas externas, como sus socios y canales;
ÿ Impacto de la organización o proyecto en el mercado, comunidad social y regiones

en que opera; y
ÿ Avanzar en el estado de la práctica en las industrias profesionales.
La mayordomía refleja la comprensión y aceptación de la confianza, así como las acciones y decisiones que
engendran y mantienen esa confianza. Los delegados también se adhieren a deberes tanto implícitos como explícitos.
Estos pueden incluir lo siguiente:

ÿ Integridad. Los delegados se comportan con honestidad y ética en todos los compromisos y comunicaciones.
Los delegados se mantienen a sí mismos con los más altos estándares y reflejan los valores, principios y
comportamientos que se esperan de aquellos en su organización. Los delegados sirven como modelos a seguir,
generando confianza al vivir y demostrar valores personales y organizacionales en sus compromisos, actividades
laborales y decisiones. En el contexto de la gestión de proyectos, este deber a menudo requiere que los delegados
desafíen a los miembros del equipo, compañeros y otras partes interesadas a considerar sus palabras y acciones;
y ser empático, autorreflexivo y abierto a la retroalimentación.
ÿ Cuidado. Los delegados son fiduciarios de los asuntos organizacionales a su cargo, y

supervisarlos diligentemente. Los proyectos de mayor rendimiento cuentan con profesionales que supervisan
diligentemente esos asuntos, más allá de los límites de las responsabilidades estrictamente definidas. Los
delegados prestan mucha atención y ejercen el mismo nivel de cuidado sobre esos asuntos como lo harían con
sus asuntos personales. El cuidado se relaciona con los asuntos comerciales internos de la organización.
El cuidado del medio ambiente, el uso sostenible de los recursos naturales y la preocupación por las
condiciones de las personas en todo el planeta deben reflejarse en las políticas y principios de la organización.
Los proyectos provocan cambios que pueden tener consecuencias imprevistas o no deseadas.
Los profesionales del proyecto deben identificar, analizar y gestionar las posibles desventajas de los
resultados del proyecto para que las partes interesadas estén conscientes e informadas.
La atención incluye la creación de un entorno de trabajo transparente, canales de comunicación abiertos y

oportunidades para que las partes interesadas planteen sus inquietudes sin penalización ni temor a represalias.

ÿ Confiabilidad. Los delegados se representan a sí mismos, sus roles, su equipo de proyecto y

su autoridad con precisión, tanto dentro como fuera de la organización. Este comportamiento
permite a las personas comprender el grado en que un individuo puede comprometer recursos,
tomar decisiones, o aprobar algo. La confiabilidad también implica que las personas sean proactivamente
identificar conflictos entre sus intereses personales y los de su organización o
clientela. Tales conflictos pueden socavar la confianza y la confianza, dar lugar a conductas poco éticas o ilegales.
comportamientos, crear confusión o contribuir a resultados subóptimos. Los mayordomos protegen
proyectos de tales abusos de confianza.
ÿ Cumplimiento. Los delegados cumplen con las leyes, normas, reglamentos y requisitos que son
debidamente autorizados dentro o fuera de su organización. Sin embargo, de alto rendimiento
proyectos buscan formas de integrar el cumplimiento más plenamente en la cultura del proyecto, creando
más alineación con pautas diversas y potencialmente contradictorias. Los mayordomos se esfuerzan por
el cumplimiento de las directrices destinadas a protegerlos a ellos, a su organización, a sus partes interesadas,
y el público en general. En los casos en que los delegados enfrenten pautas o preguntas contradictorias
con respecto a si las acciones o los planes se alinean o no con las pautas establecidas, los delegados buscan
consejo y dirección apropiados.
La mayordomía requiere liderazgo con transparencia y confiabilidad. Los proyectos afectan las vidas de las personas
que los entregan, así como las de aquellos que se ven afectados por los productos y resultados del proyecto. Los proyectos
pueden tener efectos, como aliviar la congestión del tráfico, producir nuevos medicamentos o crear oportunidades para que las
personas interactúen. Esos efectos pueden producir impactos y consecuencias negativas, como espacios verdes reducidos, efectos
secundarios de medicamentos o divulgación de información personal. Los equipos de proyecto y sus líderes organizacionales
consideran cuidadosamente dichos factores e impactos para que puedan tomar decisiones responsables al equilibrar los objetivos
organizacionales y del proyecto con las necesidades y expectativas más amplias de las partes interesadas globales.
Cada vez más, las organizaciones adoptan una visión holística de los negocios que considera el desempeño
financiero, técnico, social y ambiental de manera simultánea en lugar de secuencial. Dado que el mundo está interconectado ahora
más que nunca y tiene recursos finitos y un entorno compartido, las decisiones de administración tienen ramificaciones más allá
del proyecto.

3.2 CREAR UN AMBIENTE DE EQUIPO DE PROYECTO COLABORATIVO
EQUIPO
Los equipos de proyecto están Los proyectos son entregados por equipos de proyecto.
formados por individuos que

Los equipos de proyecto trabajan dentro de organizaciones y profesionales.
manejan diversas habilidades, culturas y pautas, a menudo estableciendo su propia cultura “local”.
conocimientos y experiencia.
Los equipos de proyecto que
Un entorno de equipo de proyecto colaborativo facilita:
trabajan en colaboración pueden
• Alineación con otras culturas organizacionales y lineamientos,
lograr un objetivo compartido de
manera más eficaz y eficiente que • Aprendizaje y desarrollo individual y en equipo, y
los individuos que trabajan por su • Contribuciones óptimas para entregar los resultados deseados.
cuenta.
Figura 3-3. Crear un entorno de equipo de proyecto colaborativo
La creación de un entorno de equipo de proyecto colaborativo implica múltiples factores que contribuyen, como los acuerdos, las estructuras y
los procesos del equipo. Estos factores respaldan una cultura que permite a las personas trabajar juntas y proporcionar efectos sinérgicos a partir de las
interacciones.

ÿ Acuerdos de equipo. Los acuerdos de equipo representan un conjunto de parámetros de comportamiento y

normas de trabajo establecidas por el equipo del proyecto y mantenidas a través del compromiso individual y del equipo
del proyecto. El acuerdo del equipo debe crearse al comienzo de un proyecto y evolucionará con el tiempo a medida que
el equipo del proyecto continúe trabajando en conjunto e identifique las normas y comportamientos que son necesarios
para continuar trabajando juntos con éxito.
ÿ Estructuras organizativas. Los equipos de proyecto usan, adaptan e implementan estructuras que ayudan a coordinar el
esfuerzo individual asociado con el trabajo del proyecto. Las estructuras organizacionales son cualquier disposición o
relación entre los elementos del trabajo del proyecto y los procesos organizacionales.
Estas estructuras pueden basarse en roles, funciones o autoridad. Se pueden definir como externos al proyecto,
adaptados para adaptarse al contexto del proyecto o diseñados recientemente para satisfacer una necesidad única del
proyecto. Una figura de autoridad puede imponer formalmente una estructura, o los miembros del equipo del proyecto
pueden contribuir a su diseño en consonancia con las estructuras organizacionales.
Ejemplos de estructuras organizacionales que pueden mejorar la colaboración incluyen, pero no son
limitado a:
ÿ Definiciones de roles y responsabilidades,
ÿ Asignación de empleados y proveedores en equipos de proyecto,
ÿ Comités formales encargados de un objetivo específico, y
ÿ Reuniones permanentes que revisan periódicamente un tema determinado.
ÿ Procesos. Los equipos de proyecto definen procesos que permiten completar tareas y asignaciones de trabajo. Por
ejemplo, los equipos de proyecto pueden acordar un proceso de descomposición utilizando una estructura de
descomposición del trabajo (WBS), trabajo pendiente o tablero de tareas.
Los equipos de proyecto están influenciados por la cultura de las organizaciones involucradas en el proyecto, la naturaleza
del proyecto y el entorno en el que operan. Dentro de estas influencias, los equipos de proyecto establecen sus propias culturas de
equipo. Los equipos de proyecto pueden adaptar su estructura para lograr mejor el objetivo del proyecto.
Al fomentar entornos inclusivos y colaborativos, el conocimiento y la experiencia se intercambian más libremente, lo que a su
vez permite mejores resultados del proyecto.

La claridad en los roles y responsabilidades puede mejorar la cultura del equipo. Dentro de los equipos de proyecto, las
tareas específicas pueden ser delegadas a individuos o seleccionadas por los propios miembros del equipo de proyecto. Esto incluye
la autoridad, la rendición de cuentas y la responsabilidad relacionada con las tareas:
ÿ Autoridad. La condición de tener el derecho, dentro de un contexto dado, a hacer

decisiones, establecer o mejorar procedimientos, aplicar recursos del proyecto, gastar fondos o
dar aprobaciones. La autoridad se confiere de una entidad a otra, ya sea que se haga explícitamente
o implícitamente.
ÿ Rendición de cuentas. La condición de ser responsable de un resultado. Responsabilidad

no se comparte.
ÿ Responsabilidad. La condición de estar obligado a hacer o cumplir algo. Responsabilidad

se puede compartir
Independientemente de quién sea responsable del trabajo de un proyecto específico, una colaboración
El equipo del proyecto se apropia colectivamente de los resultados del proyecto.
Un equipo de proyecto diverso puede enriquecer el entorno del proyecto reuniendo diferentes
perspectivas El equipo del proyecto puede estar compuesto por personal de la organización interna, colaboradores
contratados, voluntarios o terceros externos. Además, algunos miembros del equipo del proyecto se unen al proyecto a corto plazo
para trabajar en un entregable específico, mientras que otros miembros se asignan al proyecto a más largo plazo. Integrar a estas
personas con un equipo de proyecto puede desafiar a todos los involucrados. Una cultura de equipo de respeto permite las
diferencias y encuentra formas de aprovecharlas de manera productiva, fomentando la gestión eficaz de conflictos.
Otro aspecto de un entorno de equipo de proyecto colaborativo es la incorporación de la práctica

normas, códigos éticos y demás lineamientos que forman parte del trabajo profesional dentro del equipo de proyecto y de
la organización. Los equipos de proyecto consideran cómo estas guías pueden apoyar sus esfuerzos
para evitar posibles conflictos entre las disciplinas y las pautas establecidas que utilizan.
Un entorno de equipo de proyecto colaborativo fomenta el libre intercambio de información y

conocimiento. Esto, a su vez, aumenta el aprendizaje compartido y el desarrollo individual al tiempo que ofrece
resultados. Un entorno de equipo de proyecto colaborativo permite que todos contribuyan lo mejor posible
esfuerzos para entregar los resultados deseados para una organización. La organización, a su vez, se beneficiará de
entregables y resultados que respetan y mejoran sus valores, principios y cultura fundamentales.

3.3 PARTICIPAR EFECTIVAMENTE CON LAS PARTES INTERESADAS
PARTES INTERESADAS
Involucrar a las partes Las partes interesadas influyen en los proyectos, el desempeño y los resultados.
interesadas de manera
Los equipos de proyecto sirven a otras partes interesadas comprometiéndose con ellas.
proactiva y en la medida
La participación de las partes interesadas promueve de forma proactiva la entrega de valor.
necesaria para contribuir al
éxito del proyecto y la
satisfacción del cliente.
Figura 3-4. Involucrarse efectivamente con las partes interesadas
Las partes interesadas pueden ser individuos, grupos u organizaciones que pueden afectar, verse afectados o percibirse afectados por una decisión, actividad o
resultado de una cartera, programa o proyecto. Las partes interesadas también influyen directa o indirectamente en un proyecto, su desempeño o resultado, ya sea de manera positiva
o negativa.

Las partes interesadas pueden afectar muchos aspectos de un proyecto, incluidos, entre otros, los siguientes:
ÿ Alcance/ requisitos, al revelar la necesidad de agregar, ajustar o eliminar elementos del alcance
y/o requisitos del proyecto;
ÿ Programe, ofreciendo ideas para acelerar la entrega o ralentizando o deteniendo la entrega de claves
actividades del proyecto;
ÿ Costo, al ayudar a reducir o eliminar los gastos planificados o al agregar pasos,

requisitos o restricciones que aumentan el costo o requieren recursos adicionales;
ÿ Equipo del proyecto, restringiendo o permitiendo el acceso a personas con las habilidades, conocimientos y
la experiencia necesaria para lograr los resultados esperados y promover una cultura de aprendizaje;
ÿ Planes, proporcionando información para los planes o abogando por cambios en las actividades acordadas
y trabajo;
ÿ Resultados, al habilitar o bloquear el trabajo requerido para los resultados deseados;
ÿ Cultura, al establecer o influir, o incluso definir, el nivel y el carácter

del compromiso del equipo del proyecto y de la organización en general;
ÿ Realización de beneficios, al generar e identificar metas a largo plazo para que el proyecto
entrega el valor identificado previsto;
ÿ Riesgo, definiendo los umbrales de riesgo del proyecto, así como participando en posteriores
actividades de gestión de riesgos;
ÿ Calidad, identificando y exigiendo requisitos de calidad; y
ÿ Éxito, definiendo factores de éxito y participando en la evaluación del éxito.
Los interesados pueden ir y venir a lo largo del ciclo de vida del proyecto. Además, el grado de interés, influencia o
impacto de una parte interesada puede cambiar con el tiempo. Las partes interesadas, especialmente aquellas con un alto
grado de influencia y que tienen una visión desfavorable o neutral sobre un proyecto, deben involucrarse de manera efectiva
para que se comprendan sus intereses, preocupaciones y derechos. Luego, el equipo del proyecto puede abordar estas
preocupaciones a través de un compromiso y apoyo efectivos que conduzcan a la probabilidad de un resultado exitoso del
proyecto.

Identificar, analizar y comprometerse de manera proactiva con las partes interesadas desde el principio hasta el final del
proyecto ayuda a lograr el éxito.
Los equipos de proyecto son un grupo de partes interesadas. Este grupo de partes interesadas involucra a otras
partes interesadas para comprender, considerar, comunicar y responder a sus intereses, necesidades y opiniones.
El compromiso y la comunicación efectivos y eficientes incluyen determinar cómo, cuándo, con qué frecuencia y en
qué circunstancias las partes interesadas quieren y deben participar.
La comunicación es una parte clave del compromiso; sin embargo, el compromiso profundiza para incluir la conciencia de
las ideas de los demás, la asimilación de otras perspectivas y la formación colectiva de un mensaje compartido.
solución. El compromiso incluye construir y mantener relaciones sólidas a través de una comunicación bidireccional frecuente.
Fomenta la colaboración a través de reuniones interactivas, reuniones cara a cara, diálogo informal y actividades de intercambio de
conocimientos.
La participación de las partes interesadas depende en gran medida de las habilidades interpersonales, incluida la
iniciativa, la integridad, la honestidad, la colaboración, el respeto, la empatía y la confianza. Estas habilidades y actitudes pueden
ayudar a todos a adaptarse al trabajo y entre sí, aumentando la probabilidad de éxito.
El compromiso ayuda a los equipos de proyecto a detectar, recopilar y evaluar información, datos y opiniones.
Esto crea una comprensión y una alineación compartidas, lo que posibilita los resultados del proyecto. Además, estas actividades
ayudan al equipo del proyecto a adaptar el proyecto para identificar, ajustar y responder a las circunstancias cambiantes.
Los equipos del proyecto involucran activamente a otras partes interesadas a lo largo del proyecto para minimizar los
posibles impactos negativos y maximizar los impactos positivos. Los compromisos de las partes interesadas también brindan
oportunidades para un mejor desempeño y resultados del proyecto, además de aumentar la satisfacción de las partes interesadas.
Finalmente, involucrar a otras partes interesadas ayuda al equipo del proyecto a encontrar soluciones que pueden ser más
aceptables para una gama más amplia de partes interesadas.

3.4 ENFOQUE EN EL VALOR
VALOR
Evalúe y ajuste continuamente El valor es el último indicador del éxito del proyecto.
la alineación del proyecto
El valor se puede realizar a lo largo del proyecto, al final de
con los objetivos comerciales y el proyecto, o después de que el proyecto esté completo.
los beneficios y el valor
previstos. El valor y los beneficios que contribuyen al valor pueden
definirse en términos cuantitativos y/o cualitativos.
Un enfoque en los resultados permite que los equipos de proyecto respalden

los beneficios previstos que conducen a la creación de valor.
Los equipos de proyecto evalúan el progreso y se adaptan para maximizar el

valor esperado.
Figura 3-5. Centrarse en el valor
El valor, incluidos los resultados desde la perspectiva del cliente o usuario final, es el indicador de éxito final y el motor
de los proyectos. El valor se centra en el resultado de los entregables. El valor de un proyecto puede expresarse como una
contribución financiera a la organización patrocinadora o receptora.
El valor puede ser una medida del bien público logrado, por ejemplo, el beneficio social o el beneficio percibido por el
cliente del resultado del proyecto. Cuando el proyecto es un componente de un programa, la contribución del proyecto a
los resultados del programa puede representar valor.
Muchos proyectos, aunque no todos, se inician en base a un caso de negocios. Los proyectos pueden ser
iniciado debido a cualquier necesidad identificada de entregar o modificar un proceso, producto o servicio, como
contratos, declaraciones de trabajo u otros documentos. En todos los casos, la intención del proyecto es proporcionar
el resultado deseado que aborda la necesidad con una solución valiosa. Un caso de negocio puede contener
información sobre alineación estratégica, evaluación de la exposición al riesgo, estudio de viabilidad económica,
rendimiento de las inversiones, medidas de rendimiento clave esperadas, evaluaciones y alternativas
enfoques. El caso de negocio puede indicar la contribución de valor prevista del resultado del proyecto.
en términos cualitativos o cuantitativos, o ambos. Un caso de negocio contiene al menos estos
y elementos interrelacionados:

ÿ Necesidad empresarial. El negocio proporciona la justificación del proyecto, explicando por qué el proyecto
se lleve a cabo. Tiene su origen en los requisitos comerciales preliminares, que se reflejan
en el acta de constitución del proyecto u otro documento de autorización. Proporciona detalles sobre el negocio.
metas y objetivos. La necesidad comercial puede estar destinada a la organización ejecutora,
una organización cliente, una asociación de organizaciones o bienestar público. Una declaración clara
de la necesidad empresarial ayuda al equipo del proyecto a comprender los impulsores empresariales para el futuro
estado y permite que el equipo del proyecto identifique oportunidades o problemas para aumentar la
valor potencial del resultado del proyecto.
ÿ Justificación del proyecto. La justificación del proyecto está conectada con la necesidad del negocio. explica por qué
la necesidad comercial vale la pena la inversión y por qué debe abordarse en este momento.
La justificación del proyecto se acompaña de un análisis de costo-beneficio y supuestos.
ÿ Estrategia empresarial. La estrategia empresarial es la razón del proyecto y todas las necesidades son
relacionados con la estrategia para lograr el valor.
Juntos, la necesidad comercial, la justificación del proyecto y la estrategia comercial, además de los beneficios.
y posibles acuerdos, brindan al equipo del proyecto información que les permite tomar decisiones informadas para
cumplir o superar el valor comercial previsto.
Los resultados deseados deben describirse claramente, evaluarse iterativamente y actualizarse a lo largo del proyecto.
Durante su ciclo de vida, un proyecto puede sufrir cambios y el equipo del proyecto se adapta en respuesta. El equipo del
proyecto evalúa continuamente el progreso y la dirección del proyecto en comparación con los resultados deseados, las líneas
de base y el caso comercial para confirmar que el proyecto se mantiene alineado con la necesidad y entregará los resultados
previstos. Alternativamente, el caso de negocios se actualiza para capturar una oportunidad o minimizar un problema identificado
por el equipo del proyecto y otras partes interesadas. Si el proyecto o sus partes interesadas ya no están alineados con la
necesidad comercial o si parece poco probable que el proyecto brinde el valor deseado, la organización puede optar por terminar
el esfuerzo.
El valor es el valor, la importancia o la utilidad de algo. El valor es subjetivo, en el sentido de que el mismo concepto
puede tener diferentes valores para diferentes personas y organizaciones. Esto ocurre porque lo que se considera un beneficio
depende de las estrategias organizacionales, que van desde ganancias financieras a corto plazo, ganancias a largo plazo e
incluso elementos no financieros. Debido a que todos los proyectos tienen una variedad de partes interesadas, los diferentes
valores generados para cada grupo de partes interesadas deben considerarse y equilibrarse con el todo, al tiempo que se prioriza
la perspectiva del cliente.

Dentro del contexto de algunos proyectos, puede haber diferentes formas de ingeniería de valor que maximicen el valor
para el cliente, para la organización ejecutora u otras partes interesadas. Un ejemplo de esto incluye entregar la funcionalidad
requerida y el nivel de calidad con una exposición de riesgo aceptable, utilizando la menor cantidad de recursos posible y evitando
el desperdicio. A veces, especialmente en proyectos adaptativos que no tienen un alcance inicial fijo, el equipo del proyecto puede
optimizar el valor trabajando con el cliente para determinar qué características vale la pena invertir y cuáles pueden no ser lo
suficientemente valiosas como para agregarlas al resultado.
Para respaldar la realización de valor de los proyectos, los equipos de proyecto cambian el enfoque de entregables a
los resultados previstos. Hacerlo permite a los equipos de proyecto cumplir con la visión o el propósito del proyecto.
proyecto, en lugar de simplemente crear un entregable específico. Mientras que el entregable puede apoyar
el resultado previsto del proyecto, es posible que no logre por completo la visión o el propósito del proyecto. Para
ejemplo, los clientes pueden querer una solución de software específica porque piensan que la solución
resuelve la necesidad empresarial de una mayor productividad. El software es el resultado del proyecto, pero
el software en sí no permite el resultado de productividad que se pretende. En este caso, agregando un
nuevo entregable de capacitación y entrenamiento en el uso del software puede permitir una mejor productividad
Salir. Si el producto del proyecto no permite una mayor productividad, las partes interesadas pueden sentir que el
el proyecto ha fracasado. Por lo tanto, los equipos de proyecto y otras partes interesadas entienden tanto el entregable como
el resultado esperado del entregable.
La contribución de valor del trabajo del proyecto podría ser una medida a corto o largo plazo. Debido a que la contribución
de valor puede mezclarse con las contribuciones de las actividades operativas, puede ser difícil de aislar.
Cuando el proyecto es un componente de un programa, la evaluación del valor a nivel del programa también puede ser
necesaria para dirigir adecuadamente el proyecto. Una evaluación confiable del valor debe considerar todo el contexto y el ciclo
de vida completo del resultado del proyecto. Si bien el valor se obtiene con el tiempo, los procesos efectivos pueden permitir la
realización temprana de beneficios. Con una implementación eficiente y eficaz, los equipos de proyecto pueden demostrar o
lograr resultados tales como entrega priorizada, mejor servicio al cliente o un entorno de trabajo mejorado. Al trabajar con líderes
organizacionales que son responsables de poner en uso los entregables del proyecto, los líderes del proyecto pueden asegurarse
de que los entregables estén posicionados para lograr los resultados planificados.

3.5 RECONOCER, EVALUAR Y RESPONDER AL SISTEMA

INTERACCIONES
PENSAMIENTO SISTÉMICO
Reconocer, evaluar y Un proyecto es un sistema de procesos interdependientes e interactivos.

responder a las circunstancias dominios de actividad.
dinámicas dentro y alrededor
El pensamiento sistémico implica adoptar una visión holística de cómo las
del proyecto de una manera partes del proyecto interactúan entre sí y con los sistemas externos.
holística para afectar
Los sistemas cambian constantemente, lo que requiere una atención constante.
positivamente el desempeño a las condiciones internas y externas.
del proyecto.
Responder a las interacciones del sistema permite a los equipos de proyecto
aprovechar los resultados positivos.
Figura 3-6. Reconocer, evaluar y responder a las interacciones del sistema
Un sistema es un conjunto de componentes que interactúan y son interdependientes que funcionan como un todo unificado. Tomando una visión
holística, un proyecto es una entidad multifacética que existe en circunstancias dinámicas, exhibiendo las características de un sistema. Los equipos de proyecto
deben reconocer esta visión holística de un proyecto, viendo el proyecto como un sistema con sus propias partes de trabajo.
Un proyecto funciona dentro de otros sistemas más grandes, y un entregable del proyecto puede convertirse en parte de un sistema más grande
para obtener beneficios. Por ejemplo, los proyectos pueden ser parte de un programa que, a su vez, también puede ser parte de una cartera. Estas estructuras
interconectadas se conocen como un sistema de sistemas.
Los equipos de proyecto equilibran las perspectivas de adentro/afuera y de afuera/adentro para respaldar la alineación en todo el sistema de sistemas.
El proyecto también puede tener subsistemas que se requieren para integrar de manera efectiva para entregar el
resultado previsto. Por ejemplo, cuando los equipos de proyectos individuales desarrollan componentes separados de un entregable, todos los componentes
deben integrarse de manera efectiva. Esto requiere que los equipos de proyecto interactúen y alineen el trabajo del subsistema de manera regular.

El pensamiento sistémico también considera los elementos de tiempo de los sistemas, como lo que el proyecto ofrece o
permite con el tiempo. Por ejemplo, si los entregables del proyecto se publican de forma incremental, cada incremento amplía los
resultados acumulativos o las capacidades de las versiones anteriores. Los equipos de proyecto deben pensar más allá del final
del proyecto hasta el estado operativo del entregable del proyecto, para que se realicen los resultados previstos.
A medida que se desarrollan los proyectos, las condiciones internas y externas cambian continuamente. Un solo cambio
puede generar varios impactos. Por ejemplo, en un gran proyecto de construcción, un cambio en los requisitos puede
causar cambios contractuales con el contratista principal, subcontratistas, proveedores u otros. Sucesivamente,
esos cambios pueden crear un impacto en el costo, cronograma, alcance y desempeño del proyecto. Después,
estos cambios podrían invocar un protocolo de control de cambios para obtener aprobaciones de entidades en el exterior
sistemas, como los proveedores de servicios, los reguladores, los financieros y las autoridades gubernamentales.
Si bien es posible predecir algunos de los cambios por adelantado, muchos de los cambios que pueden afectar al
proyecto durante su ciclo de vida surgen en tiempo real. Con el pensamiento sistémico, incluida la atención constante a las
condiciones internas y externas, el equipo del proyecto puede navegar por un amplio espectro de cambios e impactos para
mantener el proyecto de acuerdo con las partes interesadas relevantes.
El pensamiento sistémico también se aplica a cómo el equipo del proyecto se ve a sí mismo y sus interacciones dentro
el sistema de proyectos. El sistema de proyectos a menudo reúne a un equipo de proyecto diverso comprometido a trabajar
por un objetivo común. Esta diversidad aporta valor a los equipos de proyecto, pero deben considerar cómo aprovechar
esas diferencias de manera efectiva, para que el equipo de proyecto trabaje de manera cohesiva.
Por ejemplo, si una agencia gubernamental contrata a una empresa privada para el desarrollo de una nueva tecnología, el
equipo de desarrollo puede estar formado por miembros del equipo de proyecto de ambas organizaciones.
Esos miembros del equipo del proyecto pueden tener suposiciones, formas de trabajar y modelos mentales relacionados con
la forma en que funcionan dentro de su organización de origen. En este nuevo sistema de proyectos, que combina las culturas de
una empresa privada y una agencia gubernamental, los miembros del equipo del proyecto pueden establecer una cultura de
equipo sintetizada que crea una visión, un lenguaje y un conjunto de herramientas comunes. Esto puede ayudar a los miembros
del equipo del proyecto a participar y contribuir de manera efectiva y ayudar a aumentar la probabilidad de que el sistema del
proyecto funcione.
Debido a la interactividad entre los sistemas, los equipos de proyecto deben operar con conocimiento de,
y vigilancia hacia la dinámica cambiante del sistema. Las siguientes habilidades apoyan una visión de sistemas del
proyecto:

ÿ Empatía con las áreas de negocio;
ÿ Pensamiento crítico con un enfoque general;
ÿ Cuestionamiento de supuestos y modelos mentales;
ÿ Buscar revisión y asesoramiento externos;
ÿ Uso de métodos, artefactos y prácticas integrados para que haya un entendimiento común
del trabajo del proyecto, entregables y resultados;
ÿ Uso de modelos y escenarios para visualizar cómo la dinámica del sistema puede interactuar
y reaccionar; y
ÿ Gestión proactiva de la integración para ayudar a lograr resultados comerciales.
Reconocer, evaluar y responder a las interacciones del sistema puede conducir a los siguientes resultados
positivos:
ÿ Consideración temprana de la incertidumbre y el riesgo dentro del proyecto, exploración de alternativas,

y consideración de las consecuencias no deseadas;
ÿ Capacidad para ajustar supuestos y planes a lo largo del ciclo de vida del proyecto;
ÿ Suministro de información y conocimientos continuos que informan la planificación y la entrega;
ÿ Comunicación clara de los planes, el progreso y las proyecciones a las partes interesadas relevantes;
ÿ Alineación de las metas y objetivos del proyecto con las metas, objetivos y visión de la
organización del cliente;
ÿ Capacidad de adaptarse a las necesidades cambiantes del usuario final, patrocinador o cliente
de los entregables del proyecto;
ÿ Habilidad para ver sinergias y ahorros entre proyectos o iniciativas alineados;
ÿ Habilidad para explotar oportunidades que no se capturan de otra manera o ver amenazas
planteadas por otros proyectos o iniciativas;
ÿ Claridad con respecto a la mejor medición del desempeño del proyecto y su influencia en el
comportamiento de las personas involucradas en el proyecto;
ÿ Decisiones que benefician a la organización en su conjunto; y
ÿ Identificación de riesgos más completa e informada.

3.6 DEMOSTRAR COMPORTAMIENTOS DE LIDERAZGO
LIDERAZGO
Demostrar y adaptar El liderazgo efectivo promueve el éxito del proyecto y contribuye
comportamientos de liderazgo a los resultados positivos del proyecto.
para apoyar las necesidades

Cualquier miembro del equipo del proyecto puede demostrar liderazgo
individuales y de equipo. comportamientos
El liderazgo es diferente a la autoridad.
Los líderes efectivos adaptan su estilo a la situación.
Los líderes efectivos reconocen las diferencias en la motivación entre los

miembros del equipo del proyecto.
Los líderes demuestran el comportamiento deseado en áreas de honestidad,

integridad y conducta ética.
Figura 3-7. Demostrar comportamientos de liderazgo
Los proyectos crean una necesidad única de liderazgo efectivo. A diferencia de las operaciones comerciales generales, donde los roles y las
responsabilidades a menudo se establecen y son consistentes, los proyectos a menudo involucran a múltiples organizaciones, departamentos, funciones o proveedores
que no interactúan de manera regular. Además, los proyectos pueden implicar mayores intereses y expectativas que las funciones operativas habituales. Como
resultado, una gama más amplia de gerentes, ejecutivos, colaboradores sénior y otras partes interesadas intentan influir en un proyecto. Esto a menudo crea mayores
grados de confusión y conflicto. En consecuencia, los proyectos de mayor rendimiento demuestran comportamientos de liderazgo efectivos con más frecuencia y de
más personas que la mayoría de los proyectos.
Un entorno de proyecto que prioriza la visión, la creatividad, la motivación, el entusiasmo, el estímulo,
y la empatía pueden apoyar mejores resultados. Estos rasgos a menudo se asocian con el liderazgo.
El liderazgo comprende la actitud, el talento, el carácter y los comportamientos para influir en las personas dentro de
y fuera del equipo del proyecto hacia los resultados deseados.

El liderazgo no es exclusivo de ningún rol específico. Los proyectos de alto rendimiento pueden incluir a
varias personas que muestren habilidades de liderazgo eficaces, por ejemplo, el director del proyecto, los patrocinadores,
las partes interesadas, la alta dirección o incluso los miembros del equipo del proyecto. Cualquiera que trabaje en un proyecto
puede demostrar rasgos, estilos y habilidades de liderazgo efectivos para ayudar al equipo del proyecto a realizar y entregar
los resultados requeridos.
Es importante tener en cuenta que pueden surgir más conflictos y confusión cuando hay demasiados participantes.
intentar ejercer la influencia del proyecto en múltiples direcciones desalineadas. Sin embargo, los proyectos de mayor
rendimiento muestran una combinación paradójica de más personas influyentes, cada una de las cuales contribuye con más
habilidades de liderazgo de manera complementaria. Por ejemplo: si un patrocinador articula prioridades claras, entonces un
líder técnico abre la discusión sobre las opciones de entrega, donde los contribuyentes individuales afirman los pros y los
contras hasta que el gerente del proyecto lleva la conversación a una estrategia de consenso. El liderazgo exitoso permite que
alguien influya, motive, dirija y entrene a las personas bajo cualquier condición. También incorpora características derivadas
de la cultura y las prácticas de una organización.
El liderazgo no debe confundirse con la autoridad, que es la posición de control otorgada a las personas dentro
de una organización para fomentar una función general eficaz y eficiente. La autoridad es el derecho a ejercer el poder.
La autoridad generalmente se delega a una persona por medios formales, como un documento de estatuto o un título
designado. Esta persona puede tener una descripción de su función o cargo que indique su autoridad. Autoridad denota
responsabilidad por ciertas actividades, acciones de individuos o toma de decisiones en ciertas circunstancias. Si bien las
personas pueden usar su autoridad para influir, motivar, dirigir a otros o actuar cuando otros no se desempeñan o no actúan
según lo indicado o solicitado, esto no es lo mismo que el liderazgo. Por ejemplo, los ejecutivos de la organización pueden
otorgar a alguien la autoridad para formar un equipo de proyecto para entregar un resultado. Sin embargo, la autoridad por sí
sola es insuficiente. Se necesita liderazgo para motivar a un grupo hacia un objetivo común, influir en ellos para alinear sus
intereses individuales a favor del esfuerzo colectivo y lograr el éxito como equipo de proyecto en lugar de como individuos.
El liderazgo efectivo se basa o combina elementos de varios estilos de liderazgo.

Los estilos de liderazgo documentados van desde autocrático, democrático, laissez-faire, directivo, participativo, asertivo, de
apoyo y autocrático hasta el consenso. De todos estos, ningún estilo de liderazgo único ha demostrado ser el enfoque
universalmente mejor o recomendado. En cambio, el liderazgo efectivo se muestra cuando mejor se adapta a una situación
dada. Por ejemplo:
ÿ En momentos de caos, la acción directiva crea más claridad e impulso que la colaboración
resolución de problemas
ÿ Para entornos con personal altamente competente y comprometido, la delegación empoderada provoca
más productividad que la coordinación centralizada.

Cuando los altos directivos sufren conflictos por las prioridades, la facilitación neutral ayuda más que los detalles.
recomendaciones Se cultiva la habilidad de liderazgo efectivo. Se puede aprender y desarrollar para que se convierta en
un activo profesional para el individuo, así como en un beneficio para el proyecto y sus partes interesadas.
Los proyectos de alto rendimiento muestran un patrón generalizado de mejora continua hasta el nivel personal. Un miembro del
equipo del proyecto profundiza la perspicacia del liderazgo al agregar o practicar una combinación de varias habilidades o
técnicas, que incluyen, entre otras, las siguientes:
ÿ Enfocar un equipo de proyecto en torno a objetivos acordados,
ÿ Articular una visión motivadora para los resultados del proyecto,
ÿ Búsqueda de recursos y apoyo para el proyecto,
ÿ Generar consenso sobre el mejor camino a seguir,
ÿ Superar los obstáculos para el progreso del proyecto,
ÿ Negociar y resolver conflictos dentro del equipo del proyecto y entre el equipo del proyecto
y otras partes interesadas,
ÿ Adaptar el estilo de comunicación y los mensajes para que sean relevantes para la audiencia,
ÿ Entrenar y asesorar a los miembros del equipo del proyecto,
ÿ Apreciar y recompensar conductas y contribuciones positivas,
ÿ Proporcionar oportunidades para el crecimiento y desarrollo de habilidades,
ÿ Facilitar la toma de decisiones en colaboración,
ÿ Emplear conversaciones efectivas y escuchar activamente,
ÿ Empoderar a los miembros del equipo del proyecto y delegarles responsabilidades,
ÿ Crear un equipo de proyecto cohesivo que asuma la responsabilidad,
ÿ Mostrar empatía por el equipo del proyecto y las perspectivas de las partes interesadas,
ÿ Tener autoconciencia de los propios prejuicios y comportamientos,
ÿ Gestionar y adaptarse al cambio durante el ciclo de vida del proyecto,
ÿ Facilitar una mentalidad de fallar rápido/aprender rápidamente al reconocer los errores, y
ÿ Ejemplificación de conductas deseadas.

El carácter personal importa en un líder. Una persona puede tener una gran capacidad de liderazgo, pero luego su influencia se ve
socavada por la percepción de ser egoísta o poco confiable.
Los líderes efectivos buscan ser un modelo a seguir en áreas de honestidad, integridad y conducta ética. Los líderes efectivos se enfocan en ser
transparentes, se comportan desinteresadamente y pueden pedir ayuda. Los líderes efectivos entienden que los miembros del equipo del proyecto
analizan y emulan los valores, la ética y los comportamientos que exhiben los líderes. Por lo tanto, los líderes tienen la responsabilidad adicional de
demostrar los comportamientos esperados a través de sus acciones.
Los proyectos funcionan mejor cuando los líderes entienden lo que motiva a las personas. Los equipos de proyecto pueden prosperar
cuando los miembros del equipo de proyecto utilizan rasgos, habilidades y características de liderazgo apropiados que coinciden con las necesidades
y expectativas específicas de las partes interesadas. Saber cómo comunicarse mejor o motivar a las personas, o tomar medidas cuando sea
necesario, puede ayudar a mejorar el desempeño del equipo del proyecto y manejar los obstáculos para el éxito del proyecto. Cuando lo practica
más de una persona en un proyecto, el liderazgo puede fomentar la responsabilidad compartida hacia la meta del proyecto, lo que a su vez puede
fomentar un entorno saludable y vibrante. Los motivadores incluyen fuerzas como las finanzas, el reconocimiento, la autonomía, el propósito
convincente, la oportunidad de crecimiento y la contribución personal.
El liderazgo efectivo promueve el éxito del proyecto y contribuye a los resultados positivos del proyecto.
Los equipos de proyecto, los miembros individuales del equipo de proyecto y otras partes interesadas participan a lo largo de un proyecto bien
dirigido. Cada miembro del equipo del proyecto puede enfocarse en entregar resultados usando una visión común y trabajando para lograr
resultados compartidos. El liderazgo eficaz es esencial para ayudar a los equipos de proyecto a mantener un entorno ético y adaptable.
Además, las obligaciones comerciales se pueden cumplir en función de la responsabilidad y la autoridad delegadas.
El liderazgo compartido no socava ni disminuye el papel o la autoridad de un líder designado por la organización, ni disminuye la necesidad de que
ese líder aplique el estilo y las habilidades de liderazgo correctos en el momento adecuado.
Mediante la combinación de estilos, el desarrollo continuo de habilidades y el aprovechamiento de los motivadores, cualquier miembro del
equipo del proyecto o parte interesada puede motivar, influir, asesorar y hacer crecer el equipo del proyecto, independientemente de su rol o posición.

3.7 PERSONALIZACIÓN BASADA EN EL CONTEXTO
SASTRERÍA
Diseñar el enfoque de Cada proyecto es único.
desarrollo del proyecto basado
El éxito del proyecto se basa en adaptarse al contexto único del
en el contexto del proyecto,
proyecto para determinar los métodos más apropiados de
sus objetivos, produciendo los resultados deseados.
partes interesadas, gobernanza,
Adaptar el enfoque es iterativo y, por lo tanto, es un proceso continuo a
y el medio ambiente utilizando el
lo largo del proyecto.
proceso "solo lo suficiente" para
lograr el resultado deseado
mientras se maximiza el valor,
se administran los costos y se
mejora la velocidad.
Figura 3-8. Adaptar según el contexto
Adaptarse a los objetivos únicos, las partes interesadas y la complejidad del entorno contribuye
al éxito del proyecto. La adaptación es la adaptación deliberada del enfoque, la gobernanza y los procesos para hacerlos más adecuados
para el entorno dado y el trabajo en cuestión. Los equipos de proyecto adaptan el marco apropiado que permitirá la flexibilidad para producir
resultados positivos de manera consistente dentro del contexto del ciclo de vida del proyecto. El entorno empresarial, el tamaño del equipo, el
grado de incertidumbre y la complejidad del proyecto son factores que influyen en cómo se adaptan los sistemas del proyecto. Los sistemas de
proyectos se pueden adaptar con una perspectiva holística, incluida la consideración de complejidades interrelacionadas. La adaptación tiene
como objetivo maximizar el valor, administrar las restricciones y mejorar el rendimiento mediante el uso de procesos, métodos, plantillas y
artefactos "solo suficientes" para lograr el resultado deseado del proyecto.

Junto con la PMO y considerando la gobernanza, los equipos de proyecto discuten y deciden sobre el enfoque de entrega y
los recursos necesarios para producir resultados proyecto por proyecto. Esto incluye la selección de los procesos a utilizar, el enfoque
de desarrollo, los métodos y los artefactos necesarios para entregar los resultados del proyecto. Adaptar las decisiones puede ser una
acción implícita de aceptar una metodología establecida. Por el contrario, la adaptación puede ser una acción explícita de seleccionar y
mezclar elementos específicos para adaptarse a las características únicas del proyecto y el entorno del proyecto. La adaptación es
necesaria hasta cierto punto en cada proyecto, porque cada proyecto existe en un contexto particular.
Los proyectos suelen ser únicos, incluso cuando el entregable del proyecto no parece único.
Esto se debe a que los contextos de los proyectos difieren en que la organización, sus clientes, sus canales y su entorno son
elementos dinámicos. Esos cambios y el aprendizaje continuo pueden hacer que los equipos de proyecto usen o desarrollen
diferentes métodos o enfoques en la búsqueda del éxito. El equipo del proyecto debe examinar el conjunto único de condiciones
para cada proyecto, de modo que puedan determinar los métodos más apropiados para producir los resultados deseados.
Una metodología existente o una forma común de trabajar puede informar la forma en que un proyecto
está hecho a la medida. Una metodología es un sistema de prácticas, técnicas, procedimientos y reglas utilizadas por quienes
trabajan en una disciplina. Es posible que se requiera que los equipos de proyecto asuman la metodología de la organización matriz.
Es decir, el equipo del proyecto adopta un sistema de procesos, gobernanza, métodos y plantillas que brindan orientación sobre cómo
ejecutar el proyecto. Si bien esto proporciona un grado de consistencia a los proyectos dentro de una organización, la metodología en
sí aún puede necesitar una adaptación para adaptarse a cada proyecto. Las políticas y procedimientos organizacionales prescriben
límites autorizados dentro de los cuales el equipo del proyecto puede adaptarse.
Los equipos de proyectos también pueden tener en cuenta el tiempo y el costo de los procesos de gestión de proyectos. Procesos
que no están hechos a la medida pueden agregar poco valor al proyecto o sus resultados mientras aumentan el costo y alargan el
cronograma. Adaptar el enfoque junto con los procesos, métodos y artefactos apropiados puede ayudar a los equipos de proyecto
a tomar decisiones sobre los costos relacionados con el proceso y la contribución de valor relacionada con los resultados del proyecto.
Además de decidir cómo adaptar un enfoque, los equipos de proyecto comunican las decisiones de adaptación a las partes
interesadas asociadas con ese enfoque. Cada miembro del equipo del proyecto es consciente de los métodos y procesos elegidos que
se relacionan con las partes interesadas y su función.

Adaptar el enfoque del proyecto para que se adapte a las características únicas del proyecto y sus
ambiente puede contribuir a un mayor nivel de desempeño del proyecto y una mayor probabilidad de éxito. Un enfoque de
proyecto personalizado puede producir beneficios directos e indirectos para las organizaciones, tales como:
ÿ Mayor compromiso de los miembros del equipo del proyecto porque participaron en la definición
el enfoque,
ÿ Reducción de residuos en términos de acciones o recursos,
ÿ Enfoque orientado al cliente, ya que las necesidades del cliente y otras partes interesadas son
un factor de influencia importante en la confección del proyecto, y
ÿ Uso más eficiente de los recursos del proyecto, ya que los equipos del proyecto son conscientes del peso
de los procesos del proyecto.
Los proyectos a medida pueden conducir a los siguientes resultados positivos:
ÿ Mayor innovación, eficiencia y productividad;
ÿ Lecciones aprendidas, de modo que se puedan compartir las mejoras de un enfoque de entrega específico
y aplicado a la próxima ronda de trabajo o proyectos futuros;
ÿ Mejora adicional de la metodología de una organización, con nuevas prácticas, métodos,

y artefactos;
ÿ Descubrimiento de resultados, procesos o métodos mejorados a través de la experimentación;
ÿ Integración efectiva dentro de equipos de proyecto multidisciplinarios de métodos y prácticas utilizadas

entregar los resultados del proyecto; y
ÿ Mayor adaptabilidad de la organización a largo plazo.
Adaptar un enfoque es de naturaleza iterativa y, por lo tanto, es un proceso constante en sí mismo durante el ciclo de
vida del proyecto. Los equipos de proyecto recopilan comentarios de todas las partes interesadas sobre cómo les funcionan los
métodos y los procesos personalizados a medida que avanza el proyecto para evaluar su eficacia y agregar valor a la organización.

3.8 CONSTRUIR CALIDAD EN PROCESOS Y ENTREGABLES
CALIDAD
Mantener un enfoque en La calidad del proyecto implica satisfacer las expectativas de las partes interesadas
la calidad que produzca y cumplir con los requisitos del proyecto y del producto.
entregables que cumplan con
La calidad se enfoca en cumplir con los criterios de aceptación de los entregables.
los objetivos del proyecto y
La calidad del proyecto implica asegurar que los procesos del proyecto sean
se alineen con las necesidades, usos,
apropiados y tan efectivos como sea posible.
y los requisitos de aceptación
establecidos por las partes
interesadas pertinentes.
Figura 3-9. Construir calidad en procesos y entregables
La calidad es el grado en que un conjunto de características inherentes de un producto, servicio o resultado cumple con los requisitos. La calidad
incluye la capacidad de satisfacer las necesidades declaradas o implícitas del cliente.
El producto, servicio o resultado de un proyecto (referido aquí como entregables) se mide por la calidad tanto de la conformidad con los criterios de aceptación como
de la idoneidad para el uso.

La calidad puede tener varias dimensiones diferentes, incluidas, entre otras, las siguientes:
ÿ Rendimiento. ¿El entregable funciona como el equipo del proyecto y otras partes interesadas?
¿destinado?
ÿ Conformidad. ¿El entregable es apto para su uso y cumple con las especificaciones?
ÿ Confiabilidad. ¿El entregable produce métricas consistentes cada vez que se realiza?
o producido?
ÿ Resiliencia. ¿Es el entregable capaz de hacer frente a fallas imprevistas y recuperarse rápidamente?
ÿ Satisfacción. ¿El entregable genera comentarios positivos de los usuarios finales? Esto incluye
usabilidad y experiencia de usuario?
ÿ Uniformidad. ¿El entregable muestra paridad con otros entregables producidos en el

¿Misma manera?
ÿ Eficiencia. ¿El entregable produce la mayor producción con la menor cantidad

de insumos y esfuerzo?
ÿ Sostenibilidad. ¿El entregable produce un impacto positivo en los aspectos económicos, sociales,
y parámetros ambientales?
Los equipos de proyecto miden la calidad utilizando métricas y criterios de aceptación basados en requisitos.
Un requisito es una condición o capacidad que es necesario que esté presente en un producto, servicio o resultado para
satisfacer una necesidad. Los requisitos, ya sean explícitos o implícitos, pueden provenir de las partes interesadas, un
contrato, las políticas organizacionales, los estándares o los organismos reguladores, o una combinación de estos. La calidad
está estrechamente relacionada con los criterios de aceptación del producto, tal como se describe en la declaración de trabajo
u otros documentos de diseño. Estos criterios deben actualizarse a medida que se realiza la experimentación y la priorización,
y deben validarse como parte del proceso de aceptación.
La calidad también es relevante para los enfoques del proyecto y las actividades utilizadas para producir los
entregables del proyecto. Mientras que los equipos de proyectos evalúan la calidad de un entregable mediante la inspección y
las pruebas, las actividades y los procesos del proyecto se evalúan mediante revisiones y auditorías. En ambos casos, las
actividades de calidad pueden centrarse en la detección y prevención de errores y defectos.

El objetivo de las actividades de calidad es ayudar a garantizar que lo que se entrega cumpla con los objetivos del cliente y otras
partes interesadas relevantes en el camino más directo. La intención es minimizar el desperdicio de recursos y maximizar la probabilidad
de lograr el resultado deseado.
Esto resulta en:
ÿ Mover los entregables al punto de entrega rápidamente, y
ÿ Prevenir defectos en los entregables o identificarlos de manera temprana para evitar o reducir la necesidad
para reelaboración y chatarra.
El objetivo de las actividades de calidad es el mismo, ya sea que se trate de un conjunto de requisitos inicial y bien definido o de
un conjunto de requisitos que se elaboren progresivamente y se entreguen de manera incremental.
Los procesos y prácticas de gestión de la calidad ayudan a producir entregables y resultados que cumplen con los objetivos del
proyecto y se alinean con las expectativas, los usos y los criterios de aceptación expresados por la organización y las partes interesadas
relevantes. La atención cercana a la calidad en los procesos y entregables del proyecto crea resultados positivos, que incluyen:
ÿ Entregables del proyecto que son aptos para el propósito, según lo definido por los criterios de aceptación,
ÿ Entregables del proyecto que cumplan con las expectativas de las partes interesadas y los objetivos comerciales,
ÿ Entregables del proyecto con defectos mínimos o nulos,
ÿ Entrega oportuna o acelerada,
ÿ Control de costes mejorado,
ÿ Mayor calidad de la entrega del producto,
ÿ Reelaboración y desechos reducidos,
ÿ Reducción de las quejas de los clientes,
ÿ Buena integración de la cadena de suministro,
ÿ Productividad mejorada,
ÿ Aumento de la moral y la satisfacción del equipo del proyecto,
ÿ Prestación robusta de servicios,
ÿ Mejor toma de decisiones, y
ÿ Procesos en mejora continua.

3.9 COMPLEJIDAD DE NAVEGACIÓN
COMPLEJIDAD
Evalúe y navegue La complejidad es el resultado del comportamiento humano, las interacciones del sistema,
continuamente por la incertidumbre y ambigüedad.
complejidad del proyecto La complejidad puede surgir en cualquier momento durante el proyecto.
para que los enfoques y
La complejidad puede ser introducida por eventos o condiciones que afectan
los planes permitan al equipo
el valor, el alcance, las comunicaciones, las partes interesadas, el riesgo y la
del proyecto navegar con
innovación tecnológica.
éxito el ciclo de vida del proyecto.
Los equipos de proyecto pueden permanecer atentos en la identificación de elementos de
complejidad y utilizar una variedad de métodos para reducir la cantidad

o impacto de la complejidad.
Figura 3-10. Navegar por la complejidad
Un proyecto es un sistema de elementos que interactúan entre sí. La complejidad es una característica de
un proyecto o su entorno que es difícil de manejar debido al comportamiento humano, el comportamiento del sistema y
ambigüedad. La naturaleza y el número de interacciones determinan el grado de complejidad de un proyecto.
La complejidad surge de los elementos del proyecto, las interacciones entre los elementos del proyecto y las interacciones
con otros sistemas y el entorno del proyecto. Aunque la complejidad no se puede controlar, el proyecto
los equipos pueden modificar sus actividades para abordar los impactos que ocurren como resultado de la complejidad.
Los equipos de proyecto a menudo no pueden prever la aparición de complejidad porque es el resultado de muchas interacciones,
como riesgos, dependencias, eventos o relaciones. Alternativamente, algunas causas pueden converger para producir un solo efecto complejo, lo
que dificulta aislar una causa específica de complejidad.
La complejidad del proyecto ocurre como resultado de elementos individuales dentro del proyecto y del sistema del proyecto como un todo. Por
ejemplo, la complejidad dentro de un proyecto puede amplificarse con una mayor cantidad o diversidad de partes interesadas, como agencias reguladoras,
instituciones financieras internacionales, múltiples proveedores, numerosos subcontratistas especializados o comunidades locales. Estas partes interesadas pueden
tener un impacto significativo en la complejidad de un proyecto, tanto individual como colectivamente.

Algunas de las fuentes más comunes de complejidad son:
ÿ Comportamiento humano. El comportamiento humano es la interacción de la conducta, el comportamiento, las actitudes

y la experiencia de las personas. El comportamiento humano también puede contribuir a la complejidad al introducir
elementos de subjetividad tales como agendas personales que entran en conflicto con las metas y objetivos del
proyecto. Las partes interesadas ubicadas en lugares remotos pueden tener diferentes zonas horarias, hablar
diferentes idiomas y tener diferentes normas culturales.
ÿ Comportamiento del sistema. El comportamiento del sistema es el resultado de interdependencias dinámicas dentro
y entre los elementos del proyecto. Por ejemplo, la integración de diferentes sistemas tecnológicos puede causar
amenazas que podrían afectar los resultados y el éxito del proyecto. Las interacciones entre los componentes del
sistema del proyecto pueden conducir a un riesgo interconectado, crear problemas emergentes o imprevisibles y
producir relaciones de causa y efecto poco claras y desproporcionadas.
ÿ Incertidumbre y ambigüedad. La ambigüedad es un estado de falta de claridad, de no saber qué

esperar o cómo comprender una situación. La ambigüedad puede surgir por tener muchas opciones o por la falta de
claridad sobre la elección óptima. Los eventos poco claros o engañosos, los problemas emergentes o las situaciones
subjetivas también pueden generar ambigüedad.
La incertidumbre es la falta de comprensión y conciencia de los problemas, eventos, caminos a seguir o soluciones a
seguir. La incertidumbre se ocupa de las probabilidades de acciones, reacciones y resultados alternativos. La
incertidumbre incluye incógnitas desconocidas y cisnes negros, que son factores emergentes que están completamente
fuera del conocimiento o la experiencia existente.
Dentro de un entorno complejo, la incertidumbre y la ambigüedad pueden combinarse para desdibujar las
relaciones causales hasta el punto en que las probabilidades y los impactos están mal definidos. Se vuelve
difícil reducir la incertidumbre y la ambigüedad hasta el punto en que las relaciones pueden definirse bien y, por lo
tanto, abordarse de manera efectiva.
ÿ Innovación tecnológica. La innovación tecnológica puede causar disrupción en productos, servicios, formas de
trabajo, procesos, herramientas, técnicas, procedimientos y más. La introducción de la informática de escritorio y
las redes sociales son ejemplos de innovaciones tecnológicas que han cambiado fundamentalmente la forma en
que se realiza el trabajo del proyecto. La nueva tecnología, junto con la incertidumbre de cómo se utilizará esa
tecnología, contribuye a la complejidad. La innovación tiene el potencial de ayudar a que los proyectos avancen
hacia una solución, o de interrumpir el proyecto cuando no se definen las incertidumbres asociadas, lo que lleva a
una mayor complejidad.

La complejidad puede surgir e impactar el proyecto en cualquier área y en cualquier punto del ciclo de vida del
proyecto. Los equipos de proyecto pueden identificar elementos de complejidad a lo largo del proyecto observando
continuamente el componente del proyecto, así como el proyecto en su conjunto, en busca de signos de complejidad. El
conocimiento del pensamiento sistémico, los sistemas adaptativos complejos, la experiencia del trabajo de proyectos anteriores,
la experimentación y el aprendizaje continuo relacionado con la interacción del sistema conducen a una mayor capacidad del
equipo del proyecto para navegar por la complejidad cuando surge. Estar atento a las indicaciones de complejidad permite que
los equipos de proyecto adapten sus enfoques y planes para navegar por posibles interrupciones para la entrega efectiva del proyecto.

3.10 OPTIMIZAR LAS RESPUESTAS AL RIESGO
RIESGO
Evaluar continuamente la Los riesgos individuales y generales pueden afectar los proyectos.
exposición al riesgo, tanto
Los riesgos pueden ser positivos (oportunidades) o negativos (amenazas).
de oportunidades como de amenazas,
para maximizar los impactos Los riesgos se abordan continuamente a lo largo del proyecto.
positivos y minimizar los La actitud, el apetito y el umbral de riesgo de una organización influyen en cómo
impactos negativos en el se aborda el riesgo.
proyecto y sus resultados.

Las respuestas al riesgo deben ser:
• Apropiado para la importancia del riesgo,
• Económico,
• Realista dentro del contexto del proyecto,
• Acordado por las partes interesadas relevantes, y
• Propiedad de una persona responsable.
Figura 3-11. Optimice las respuestas al riesgo
Un riesgo es un evento o condición incierta que, si ocurre, puede tener un efecto positivo o negativo
en uno o más objetivos. Los riesgos identificados pueden o no materializarse en un proyecto. Los equipos de proyecto se esfuerzan por identificar y
evaluar los riesgos conocidos y emergentes, tanto internos como externos al proyecto, a lo largo del ciclo de vida.
Los equipos de proyecto buscan maximizar los riesgos positivos (oportunidades) y disminuir la exposición a los riesgos negativos (amenazas). Las
amenazas pueden generar problemas como retrasos, sobrecostos, fallas técnicas, deficiencias en el rendimiento o pérdida de reputación. Las oportunidades
pueden conducir a beneficios tales como reducción de tiempo y costo, mejor desempeño, mayor participación de mercado o mejor reputación.

Los equipos de proyecto también monitorean el riesgo general del proyecto. El riesgo general del proyecto es el efecto de la
incertidumbre en el proyecto como un todo. El riesgo general surge de todas las fuentes de incertidumbre, incluidos los riesgos
individuales, y representa la exposición de las partes interesadas a las implicaciones de las variaciones en los resultados del proyecto,
tanto positivas como negativas. La gestión del riesgo general del proyecto tiene como objetivo mantener la exposición al riesgo del
proyecto dentro de un rango aceptable. Las estrategias de gestión incluyen la reducción de los impulsores de las amenazas, la
promoción de los impulsores de las oportunidades y la maximización de la probabilidad de lograr los objetivos generales del proyecto.
Los miembros del equipo del proyecto interactúan con las partes interesadas relevantes para comprender su apetito por
el riesgo y los umbrales de riesgo. El apetito por el riesgo describe el grado de incertidumbre que una organización o individuo
está dispuesto a aceptar en previsión de una recompensa. El umbral de riesgo es la medida de variación aceptable en torno a un
objetivo que refleja el apetito por el riesgo de la organización y las partes interesadas. El umbral de riesgo refleja el apetito por el
riesgo. Por lo tanto, un umbral de riesgo de ±5 % en torno a un objetivo de coste refleja un menor apetito por el riesgo que un umbral
de riesgo de ±10 %. El apetito por el riesgo y el umbral de riesgo informan cómo el equipo del proyecto navega por el riesgo en un
proyecto.
Las respuestas de riesgo efectivas y apropiadas pueden reducir las amenazas individuales y generales del proyecto y
aumentar las oportunidades individuales y generales. Los equipos de proyecto deben identificar de manera consistente las posibles
respuestas a los riesgos teniendo en cuenta las siguientes características:
ÿ Adecuadas y oportunas a la importancia del riesgo,
ÿ Rentable,
ÿ Realista dentro del contexto del proyecto,
ÿ Acordado por las partes interesadas relevantes, y
ÿ Propiedad de una persona responsable.
Los riesgos pueden existir dentro de la empresa, cartera, programa, proyecto y producto. El proyecto puede ser un
componente de un programa en el que el riesgo puede potencialmente mejorar o disminuir la realización de beneficios y, por lo
tanto, el valor. El proyecto puede ser un componente de una cartera de trabajo relacionado o no relacionado en el que el riesgo
puede aumentar o disminuir potencialmente el valor general de la cartera y la realización de los objetivos comerciales.
Las organizaciones y los equipos de proyectos que emplean una evaluación y planificación de riesgos consistentes y
una implementación proactiva de riesgos a menudo encuentran que el esfuerzo es menos costoso que reaccionar a los problemas cuando
el riesgo se materializa.
Se puede encontrar más información sobre la gestión de riesgos en The Standard for Risk Management in Portfolios,
Programs, and Projects [3].

3.11 APROVECHE LA ADAPTABILIDAD Y LA RESILIENCIA
ADAPTABILIDAD Y RESILIENCIA
Incorpore adaptabilidad y La adaptabilidad es la capacidad de responder a las condiciones cambiantes.
resiliencia en los enfoques
La resiliencia es la capacidad de absorber impactos y recuperarse
de la organización y del equipo rápidamente de un contratiempo o falla.
del proyecto para ayudar a que
Un enfoque en los resultados en lugar de los productos facilita la adaptabilidad.
el proyecto se adapte al cambio,
se recupere de los contratiempos
y avance en el trabajo del
proyecto.
Figura 3-12. Adopte la adaptabilidad y la resiliencia
La mayoría de los proyectos encuentran desafíos u obstáculos en algún momento. Los atributos combinados de adaptabilidad y resiliencia en el
enfoque del equipo del proyecto ayudan a que el proyecto se adapte a los impactos y prospere. La adaptabilidad se refiere a la capacidad de responder a las
condiciones cambiantes. Resistencia
consta de dos rasgos complementarios: la capacidad de absorber impactos y la capacidad de recuperarse rápidamente de un contratiempo o falla. Tanto la
adaptabilidad como la resiliencia son características útiles para cualquiera que trabaje en proyectos.

Un proyecto rara vez se realiza exactamente como se planeó inicialmente. Los proyectos están influenciados por factores internos
y externos (nuevos requisitos, problemas, influencias de las partes interesadas, entre otros factores) que existen en un sistema de
interacciones. Algunos elementos dentro de un proyecto pueden fallar o no cumplir con las expectativas, lo que requiere que el equipo del
proyecto se reagrupe, reconsidere y vuelva a planificar. En un proyecto de infraestructura, por ejemplo, una decisión judicial durante la
ejecución del proyecto podría cambiar los diseños y planes. En un proyecto de tecnología, un modelo computarizado de la tecnología puede
mostrar que los componentes funcionan juntos correctamente, pero la aplicación del mundo real falla. En ambos casos, el equipo del proyecto
deberá abordar la situación para hacer avanzar el proyecto. La opinión de que los proyectos deben apegarse a los planes y compromisos
asumidos durante las primeras etapas, incluso después de que surjan factores nuevos o imprevistos, no es beneficiosa para las partes
interesadas, incluidos los clientes y usuarios finales, ya que limita el potencial de generación de valor.
Sin embargo, la adaptación se debe hacer con una visión holística, como un proceso de control de cambios adecuado, para evitar problemas
como el aumento del alcance. En un entorno de proyecto, las capacidades que respaldan la adaptabilidad y la resiliencia incluyen:
ÿ Bucles de retroalimentación cortos para adaptarse rápidamente;
ÿ Aprendizaje y mejora continua;
ÿ Equipos de proyectos con amplios conjuntos de habilidades, junto con personas que tienen amplios conocimientos
en cada área de habilidad requerida;
ÿ Inspección regular y adaptación del trabajo del proyecto para identificar oportunidades de mejora;
ÿ Diversos equipos de proyecto para capturar una amplia gama de experiencias;
ÿ Planificación abierta y transparente que involucra a las partes interesadas internas y externas;
ÿ Prototipos y experimentos a pequeña escala para probar ideas y probar nuevos enfoques;
ÿ Habilidad para aprovechar nuevas formas de pensar y trabajar;
ÿ Diseño de procesos que equilibre la velocidad del trabajo y la estabilidad de los requisitos;
ÿ Conversaciones organizacionales abiertas;
ÿ Diversos equipos de proyecto con amplios conjuntos de habilidades, culturas y experiencia, junto
expertos en la materia en cada área de habilidad requerida;
ÿ Comprensión del aprendizaje pasado de los mismos o similares esfuerzos;

ÿ Habilidad y disposición para anticipar múltiples escenarios potenciales y prepararse para múltiples
eventualidades;
ÿ Aplazar la toma de decisiones hasta el último momento responsable;
ÿ Apoyo a la gestión; y
ÿ Diseño abierto que equilibra velocidad y estabilidad.
Visualizar resultados en lugar de entregables puede habilitar soluciones, aprovechando un resultado mejor
que el planeado originalmente. Por ejemplo, un equipo de proyecto puede encontrar una solución alternativa que
proporcione mejores resultados que el entregable definido originalmente. Si bien la exploración de alternativas suele ser
el ámbito del caso comercial, las tecnologías y otras capacidades están evolucionando tan rápidamente que podría surgir
una solución en cualquier momento entre la finalización del caso comercial y el cierre del proyecto. Las oportunidades de
adaptación pueden surgir durante un proyecto, momento en el que el equipo del proyecto debe presentar argumentos al
patrocinador del proyecto, al propietario del producto o al cliente para aprovechar la oportunidad. Dependiendo del tipo de
contrato, puede ser necesaria la aprobación del cliente para algunos de los cambios que resulten de la adaptación. El equipo
del proyecto debe estar preparado para adaptar sus planes y actividades para aprovechar la oportunidad, con el apoyo del
patrocinador del proyecto, el propietario del producto o el cliente.
Los cambios y circunstancias inesperados en un sistema de proyectos también pueden presentar oportunidades.
Para optimizar la entrega de valor, los equipos de proyectos deben utilizar la resolución de problemas, así como un
enfoque de pensamiento holístico para los cambios y eventos no planificados. Cuando ocurre un evento no planificado, los
equipos de proyecto deben buscar posibles resultados positivos que puedan obtenerse. Por ejemplo, incorporar un cambio
que ocurre tarde en la línea de tiempo de un proyecto podría agregar una ventaja competitiva al ser el primer producto en el
mercado en ofrecer la función.
Desarrollar adaptabilidad y resiliencia en un proyecto mantiene a los equipos de proyectos enfocados en el

resultado deseado cuando cambian los factores internos y externos, y los ayuda a recuperarse de los contratiempos. Estas
características también ayudan a los equipos de proyectos a aprender y mejorar para que puedan recuperarse rápidamente
de fallas o contratiempos y continuar progresando hacia la entrega de valor.

3.12 HABILITAR EL CAMBIO PARA LOGRAR LO PREVISTO

ESTADO FUTURO
CAMBIO
Preparar a los afectados Un enfoque estructurado del cambio ayuda a individuos, grupos y
para la adopción y la transición de la organización del estado actual a un futuro
mantenimiento de estado deseado.
comportamientos y El cambio puede originarse a partir de influencias internas o externas.

procesos nuevos y diferentes fuentes.
necesarios para la transición
Permitir el cambio puede ser un desafío ya que no todas las partes interesadas
del estado actual al estado aceptar el cambio.
futuro previsto creado por
Intentar demasiados cambios en poco tiempo puede provocar fatiga y/o
los resultados del proyecto.
resistencia al cambio.
La participación de las partes interesadas y los enfoques motivacionales ayudan a

cambio de adopción.
Figura 3-13. Habilite el cambio para lograr el estado futuro previsto
Permanecer relevante en el entorno empresarial actual es un desafío fundamental para todas las organizaciones. La relevancia implica
responder a las necesidades y deseos de las partes interesadas. Esto requiere evaluar continuamente las ofertas en beneficio de las partes interesadas,
responder rápidamente a los cambios y actuar como agentes del cambio. Los gerentes de proyecto están en una posición única para mantener a una
organización preparada para los cambios. Los proyectos, por su propia definición, crean algo nuevo: son agentes de cambio.
La gestión del cambio, o habilitación, es un enfoque integral, cíclico y estructurado para
hacer la transición de individuos, grupos y organizaciones de un estado actual a un estado futuro en el que obtienen los beneficios deseados. Es diferente
del control de cambios del proyecto, que es un proceso mediante el cual se identifican y documentan las modificaciones a los documentos, entregables o líneas
base asociadas con el proyecto, y luego se aprueban o rechazan.

El cambio en una organización puede originarse en fuentes internas, como la necesidad de una nueva capacidad o en respuesta
a una brecha de desempeño. El cambio también puede originarse en fuentes externas, como avances tecnológicos, cambios demográficos o
presiones socioeconómicas. Cualquier tipo de cambio implica cierto nivel de adaptabilidad o asimilación por parte del grupo que experimenta el
cambio, así como de las industrias con las que interactúa el grupo.
El cambio puede ser implementado por las partes interesadas y tener consecuencias para ellas. Permitir el cambio de
las partes interesadas es parte de facilitar que el proyecto proporcione el entregable requerido, así como el resultado previsto.
Permitir el cambio en una organización puede ser un desafío. Algunas personas pueden parecer inherentemente
resistentes al cambio o aversión al riesgo, y los entornos pueden mostrar una cultura conservadora, entre otras razones. La gestión eficaz
del cambio utiliza una estrategia de motivación en lugar de una contundente. El compromiso y la comunicación bidireccional crean un
entorno en el que puede ocurrir la adopción y asimilación del cambio o identificar algunas preocupaciones válidas de los usuarios que se
resisten y que pueden necesitar ser abordadas.
Los miembros del equipo del proyecto y los gerentes del proyecto pueden trabajar con las partes interesadas relevantes para abordar
la resistencia, la fatiga y la absorción del cambio para aumentar la probabilidad de que los clientes o los destinatarios de los entregables
del proyecto adopten o asimilen con éxito el cambio. Esto incluye comunicar la visión y los objetivos asociados con el cambio al principio
del proyecto para lograr la aceptación del cambio. Los beneficios del cambio y el impacto en los procesos de trabajo deben comunicarse a
todos los niveles de la organización a lo largo del proyecto.
También es importante adaptar la velocidad del cambio al apetito por el cambio, el costo y la capacidad de las partes interesadas
y el entorno para asimilar el cambio. Intentar crear demasiados cambios en un tiempo demasiado corto puede generar resistencia debido a la
saturación de cambios. Incluso cuando las partes interesadas acuerdan por unanimidad que el cambio producirá más valor o mejorará los
resultados, a menudo todavía tienen dificultades para trabajar en las acciones que generarán mayores beneficios. Para fomentar la realización
de beneficios, el proyecto también puede incluir actividades para reforzar el cambio después de su implementación para evitar que las personas
regresen al estado inicial.
Reconocer y abordar las necesidades de las partes interesadas para adoptar el cambio a lo largo del ciclo de vida del proyecto
ayuda a integrar el cambio resultante en el trabajo del proyecto, lo que hace más probable un resultado exitoso.
Puede encontrar más información sobre la gestión del cambio organizacional en Gestión del cambio
en Organizaciones: una guía práctica [4].

REFERENCIAS
[1] Instituto de Gestión de Proyectos. 2016. PMI Léxico de términos de gestión de proyectos. Disponible en http://
www.pmi.org/lexiconterms
[2] Instituto de Gestión de Proyectos. 2006. Código de Ética y Conducta Profesional del PMI. Disponible en http://
www.pmi.org/codeofethics
[3] Instituto de Gestión de Proyectos. 2019. La Norma para la Gestión de Riesgos en Portafolios, Programas y Proyectos.
Newtown Square, Pensilvania: Autor.
[4] Instituto de Gestión de Proyectos. 2013. Gestión del cambio en las organizaciones: una guía práctica.
Newtown Square, Pensilvania: Autor.

Índice
Realización de beneficios
UN
partes interesadas y, 32
Investigación académica, 18 Caso de negocio
Criterios de aceptación, 48 contenido de, 34
Rendición de iniciación de proyectos y, 34

cuentas entorno de equipo de proyecto colaborativo y, 30 soluciones y, 57 actualización, 35
Escucha activa, 42 valor y, 34

Definición de
adaptabilidad, 55 dirección comercial, 15
resiliencia y, principio, 55–57 Ambiente de negocios, 42, 58
Entornos adaptables necesidad empresarial, 35
dirección, perspicacia y, 15 Requisitos comerciales, 35

retroalimentación y, 14 estrategia empresarial, 35
equipo de
acuerdos, 29
Definición de C
ambigüedad, 51
Cuidado, mayordomía y, 26
incertidumbre y, 51
Cambio
Supuesto(s), 35, 39
que permite lograr el estado futuro previsto, principio 58–59
audiencia, 5
origen de, 59 inesperado, 57
Auditorías, calidad, 48
Entorno de
equipo de proyecto de colaboración de autoridad y, 30 liderazgo
Cambiar el apetito, 59
contrastado con, 41
proyecto de control
Toma de decisiones autocrática, 41;
de cambios, 58
pensamiento sistémico y, 54
Gestión del cambio, Carta 58.
B
Véase Acta de constitución del proyecto; Carta del equipo
Código de ética, 21 Ambiente de equipo de proyecto
Comportamiento colaborativo, principio 28–30 estructuras organizacionales,
humano, 51 sistema, 51 29 procesos y, 29 roles, responsabilidades y, 30
Beneficio(s) acuerdos de equipo, 29
enfoque de proyecto personalizado y, 46 valor
y, 10

Índice 61
bases de datos comerciales, 18

Y
Comunicación
conversación, 41 Eficiencia, 48
compromiso y, 33 Capacidad de los empleados,
bidireccional, 59 17 Compromiso. Véase también Comunicación de
Competencias, 17, 20 participación de los grupos de interés y, 33, 59 Medio
Definición de complejidad, 50 ambiente. Véase también Entornos adaptativos; Globalización/
navegación de, principio, medio ambiente global; entorno del proyecto
50–52 proyecto, 50 ciclo de vida del empresarial, 42, 58 externo, 18 interno, 16–17 físico,
proyecto y, 52 fuentes de, 51 18 normativo, 18 Ética, código de, 21 Experiencia, 15
Cumplimiento, administración y, 24, entorno externo, 18
27 Confidencialidad , 17 Sistemas de
gestión de configuración, 17 Conformidad,
48 Contexto, adaptación basada en,
principio, 44–46 Contratista(s), 38. Véase
también Conversación de subcontratistas, 41
F
Coordinación
Habilidad de
supervisión y, 13 tipos
liderazgo de facilitación y, 42
de, 12
apoyo y, 14
Análisis de costo-beneficio, 35
Criterios Instalaciones, distribución geográfica de, 17
estudio de viabilidad, 34
aceptación, 48, 49
Influencias y problemas culturales, 18 Retroalimentación, objetivos y, 13–14
Consideraciones financieras, 18
Cultura, organización y, 17
D GRAMO
Activos de datos, Principios generales de gestión, 22 Distribución
17 Bases de datos, comerciales, geográfica de instalaciones/recursos, 17 Gobernanza. Ver
18 Entregable(s). Ver también Resultado(s) también Gobernanza organizacional

mantenimiento, 16
construyendo calidad en procesos y, principio 47–49
cultura organizacional, estructura y, 17 portafolio,
flujo de información y, 11 19 proyecto, 11 sistemas, organizacional, 12
resultados y, 10, 34, 36, 57 productos

como, 18, 20 actividades de calidad
Documentación de gobernanza, 17
y, 48
dominios Consulte Dominios de rendimiento; Dominios
de rendimiento del proyecto

Comportamientos de liderazgo, principio, 40–43

H
autoridad contrastada con, 41 motivadores y,
Proyectos de alto rendimiento, 42 43 facilitación neutral y, 42 carácter personal y,
Enfoque de pensamiento holístico, 57 43 estilos de liderazgo, 41
Visión holística, 27, 37, 44, 56
Comportamiento humano, 51
Entornos híbridos dirección, Habilidades y técnicas de liderazgo, 42

conocimiento y, 15
retroalimentación y, 14
METRO
yo
Administración. Véase también Gestión de productos;
Gestión de programas; Cambio de gestión de proyectos,
Mejora continua, 42
58 riesgo, 32 cadena de suministro, 8 Gerente(s). Ver también
Estándares de la industria, 18
Project manager Metodología, definición, 45 Seguimiento del
Liderazgo
riesgo del proyecto y, 54
de influencia y, 41
stakeholders y, 31, 32
Flujo de información, sistema de entrega de valor, 11
software de tecnología de la información, 17
Infraestructura, 17
Motivación
Innovación
gestión del cambio y, 59 liderazgo y,
facilitación de, 16
43
tecnológico, 51
Insights
business direction y, 15
norte
contribuyendo, 14
Inspección, 48, 56
Navegar complejidad, principio, 50
integridad, 26
Riesgos negativos (amenazas), 53
Entorno interno, 16–17
Habilidades interpersonales
participación de los grupos de interés y, 33
LA
k
Retroalimentación de objetivos y, 13–14
Conceptos clave, 4–5 Adaptación de
Términos clave, 4–5 oportunidades y, 57

identificación de, 16
Activos de conocimiento, 17
maximización, 53, 54
Organización(es)
L definición, 7
cultura organizacional, 17
Liderazgo.
Sistemas de gobierno organizacional,
autoridad contrastada con, 41 carácter
12
y, 43 motivación y, 43 compartida, 43
Estructura(s) organizativa(s)
estilos y, 41
entorno de equipo de proyecto colaborativo y, 29

Índice 63
Definición de Proceso(s)
resultado(s), 4 sastrería, 45
previsión, 57 Definición de
liderazgo y 43 partes producto(s), 4

interesadas y 32 interacciones ciclo de vida del
del sistema y 39 proyectos de producto definición,
adaptación y 46 actualización de 35 19 gestión de productos dentro, 19, 20 gestión de

Producto(s). resultados y, 4, 35, 55 programas dentro, 20 gestión de proyectos dentro,
Supervisión, coordinación y, 13 20 muestra, 19
Gestión de productos
consideraciones, 18–20 formas
de, 20 dentro de un programa,
PAG
20
Conducta profesional, 21
Parámetros, 29
Definición de
Desempeño, 48
programa(s), 4
Organización ejecutante, 4, 35, 36 Ambiente
gestión de productos dentro, 20
físico, 18 PM. Véase la definición de la(s)
Gestión de programas dentro
cartera(s) del director de proyecto, 4 gobernanza
del ciclo de vida del producto, 20
de, 19, 20 flujo de información y, 11 Riesgos
Proyecto(s)
positivos, 53. Véase también Principios de
como agentes de cambio, 58
oportunidades, adaptabilidad y resiliencia
caso de negocio y, 34 definición,
de la gestión de proyectos, abrazar, 55–57
4, 50 efectos de, 27
el cambio, permitir alcanzar el estado futuro previsto ,
retroalimentación y, 14 funciones
58–59 entorno de equipo de proyecto colaborativo, 28–
asociadas con, 12–16 factores
30 complejidad, navegación de, 50–52 principios generales de
internos y externos, 55 singularidad y, 45
gestión y, 22 comportamientos de liderazgo, 40–43 descripción
general, 21–23 etiquetas de principios, 23 calidad, construcción
en procesos y entregables, 47 –49 respuestas al riesgo,

Control de cambios de proyectos, 58
optimización, 53–54 participación de las partes interesadas, 31–
cierre del proyecto, 16, 57
33 administración, 24–27 interacciones del sistema y, 37–39
complejidad del proyecto, 50
adaptación, contexto y, 44–46 valor, enfoque en, 34–36 resolución
Adaptabilidad del entorno
de problemas, 57 activos del proceso , 17
del proyecto, resiliencia y, 56–57 entorno
externo, 18 entorno interno, 16–17
Gobernanza del proyecto, 11

Justificación del proyecto, 35
Complejidad del ciclo
de vida del proyecto y, 50, 52
Adaptación y, 46
definición de gestión de
proyectos, 4 dentro del
ciclo de vida de un producto, 20 dentro

de un programa, 20 valores y, 21

Principios de gestión de proyectos q

adaptabilidad y resiliencia, aceptación, 55–57 cambio, habilitación
para lograr el estado futuro previsto, 58–59 entorno de equipo de Calidad
proyecto colaborativo, 28–30 complejidad, navegación de, 50–52 para procesos y entregables, principio, 47–49 definición,
principios generales de gestión y, 22 comportamientos de 47 dimensiones de, 48
liderazgo, 40 –43 descripción general, 21–23 etiquetas de

principios, 23 calidad, construcción en procesos y entregables,
47–49 respuestas de riesgo, optimización, 53–54 participación de Actividades de calidad, 48
las partes interesadas, 31–33 administración, 24–27 interacciones Procesos de gestión de la calidad, resultados positivos
del sistema y, 37–39 personalización, contexto y, 44–46 valor, de, 49
centrarse en, 34–36 Identificación de requisitos de

calidad de, 32
Entorno regulatorio, 18 Relevancia, 58

Confiabilidad, 48 Cambio solicitado, 13
Requisito(s). negocio, 35 definición, 48

Equipo de gestión de proyectos. Véase también Equipo(s) de
proyecto, 4, 14, 32 Investigación,
proyecto
académico, 18 Resiliencia, 48
Gerente de proyecto (PM). Véase también Competencias;
Resiliencia adaptabilidad y, principio,
Definición de habilidades
55–57 definición, 55 Recursos
de liderazgo, 4
disponibilidad de, 17 dirección y,
Requisitos del proyecto, 4, 14, 32
15–16 distribución geográfica de , 17
exposición al
Responsabilidad, entorno de equipo de
riesgo del proyecto,
proyecto colaborativo y, 30 Riesgo(s).
54 gestión de, 54
Ver también Oportunidades; riesgo del proyecto;
patrocinador del proyecto, 57
Definición de amenaza(s), 53 identificación de,
Interesado(s) del proyecto
53 negativa (amenazas), 53 positiva (oportunidades),
externo, 25, 56
53 equipos de proyecto y, 53–54 Definición de
Liderazgo para el
apetito de riesgo, 54 Actitud de riesgo, 53
éxito del proyecto y, 43
personalización y, 44
equipo(s) de proyecto.
complejidad y, 52 definición,
5 diversa, 30 medición de
la calidad y, 48 riesgo y,
53–54 partes interesadas y, 33

pensamiento sistémico y, 38 adaptación
y, 45 entorno del equipo del proyecto,
colaborativo, 28–30

Índice sesenta y cinco
Respuestas al riesgo, optimización, principio, 53–54 Facilitación

Umbral de riesgo, 54 de apoyo y, 14
Claridad Sostenibilidad, 25, 48
de roles en, 30 Definición de
definiciones de, 53 sistema(s), 37
liderazgo y, 40, 41 sistema de, 37

Comportamiento del sistema, 51
Sistema para la entrega de valor, 7–20

S componentes de, sistema de muestra, 10
creación de valor, 7–11 definición, 5 ejemplo de,
Seguridad, protección y, 17
9 funciones asociadas con proyectos, 12–16
satisfacción, 48
flujo de información y, 11 sistemas de gobierno
Deslizamiento del alcance, 55, 56
organizacional y, 12 descripción general, 7 consideraciones
Seguridad, protección y, 17
de gestión de productos, 18 entorno del proyecto, dieciséis
Habilidades
liderazgo, 41 vista
de sistemas y, 38–39
Influencias y problemas sociales, 18
redes sociales, 51
Interacciones del sistema, principio, 37–39
Software
resultados positivos y, 39
tecnología de la información, 17
Condiciones internas y
realización de valor y, 36 organización
externas de pensamiento sistémico, 38 equipo
patrocinadora, 19 partes interesadas.
de proyecto y, 38 habilidades y, 38–39 elementos
Véase también Interesado(s) externo(s) del proyecto, 25, 56
de tiempo y, 38
aspectos del proyecto y, 32 equipos de proyecto como
grupo de, 33 Cambio de los interesados, 59 Compromiso

de los interesados, efectivo, principio,
T
31–33 Adaptar los
Expectativas de las partes interesadas, beneficios, directos e indirectos, 46
49 Estándares, industria, 18 contexto y, principio, 44–46 definición, 44

Administración, principio, 24–27 cuidado resultados positivos y, 46 equipo(s). Ver
y, 26 cumplimiento y, 27 deberes, equipo(s) de proyecto
25–27 integridad y, 26 significados y
contextos, 25 dentro de la Acuerdos de equipo, 29
organización, 25 fuera de la Ambiente de equipo, colaboración, principio, 28–30
organización, 25 descripción general,
24 confiabilidad y, 27 Subcontratista(s), Innovación tecnológica, 51
17, 38, 50 Programas subsidiarios, 4, Amenaza(s)
20 Éxito, 32. Véase también Valor del a la que disminuye la exposición, 53
éxito del proyecto y, 34 Límite
riesgo, 54
Confiabilidad, mayordomos y, 27

Aportación de valor, 36
EN
Entrega de valor. Véase también Sistema de entrega de valor
Incertidumbre, componentes, 8
ambigüedad y, 51 ingeniería de valor, 36
definición, 51 Realización del valor, 36
Uniformidad, 48 variaciones, 54
EN En
Valor. Véase también Sistema para la creación EDT. Ver estructura de descomposición del trabajo
de entrega de valor, 7–11 definición, 5, 35 Trabajo, desempeño de, 14

componentes de entrega, 8–10 enfoque en, Descomposición de la estructura de
principio, 34–36 optimización de, 57 desglose del trabajo (WBS) y, 29

Índice 67

UNA GUIA PARA

LA GESTIÓN DE PROYECTOS
CUERPO DE CONOCIMIENTOS
(GUÍA PMBOK®)
La información contenida en la
Guía PMBOK® no es un estándar
nacional estadounidense (ANS) y no
ha sido procesada de acuerdo con los
requisitos de ANSI para un ANS.
Como tal, la información en la
Guía del PMBOK® puede contener
material que no ha sido sujeto a revisión
pública o a un proceso de consenso.
Además, no contiene requisitos
conformidad con un estándar ANS.

1
Introducción
Esta sección describe información importante acerca de la Guía de los Fundamentos para la Dirección
de Proyectos (Guía del PMBOK® ) , séptima edición. Describe la relación de la Guía del PMBOK® con The
Standard for Project Management [1],1 cambios a la Guía del PMBOK® , la relación con PMIstandards+™ (la
plataforma digital de PMI para estándares) y proporciona una breve descripción general del contenido.
1.1 ESTRUCTURA DE LA GUÍA PMBOK ®
Además de esta Introducción, esta edición de la Guía del PMBOK® contiene tres secciones:
ÿ Sección 2 Dominios de rendimiento del proyecto. Esta sección identifica y describe ocho
dominios de desempeño del proyecto que forman un sistema integrado para permitir la entrega exitosa
del proyecto y los resultados previstos.
ÿ Sección 3 Sastrería. Esta sección describe qué es la adaptación y presenta una descripción general
de qué adaptar y cómo adaptar los proyectos individuales.
ÿ Sección 4 Modelos, métodos y artefactos. Esta sección presenta una breve descripción
de modelos, métodos y artefactos de uso común. Estos modelos, métodos y artefactos ilustran la
gama de opciones que los equipos de proyecto pueden usar para producir entregables, organizar el
trabajo y permitir la comunicación y la colaboración.
1 Los números entre paréntesis se refieren a la lista de referencias al final de la Guía del PMBOK® .

3
1.2 RELACIÓN DE LA GUÍA PMBOK ® Y

El trabajo en los dominios de desempeño del proyecto se guía por los principios de la gestión de proyectos.
Como se describe en The Standard for Project Management [1], un principio es una norma, verdad o valor
fundamental. Los principios para la gestión de proyectos brindan orientación para el comportamiento de las personas
involucradas en los proyectos, ya que influyen y dan forma a los dominios de desempeño para producir los resultados
previstos. Si bien existe una superposición conceptual entre los principios y los dominios de desempeño, los principios
guían el comportamiento, mientras que los dominios de desempeño presentan amplias áreas de enfoque en las que
demostrar ese comportamiento. La figura 1-1 muestra cómo los principios de gestión de proyectos se ubican por encima
de los dominios de desempeño, brindando orientación para las actividades en cada dominio de desempeño.

4 Guía PMBOK®
Principios de la gestión de proyectos
Ser un mayordomo diligente, Crear un entorno de equipo Comprometerse efectivamente

Centrarse en el valor
respetuoso y solidario. colaborativo con las partes interesadas
Reconocer, evaluar y
Demostrar comportamientos de Incorpore calidad en
responder a las Adaptar según el contexto
liderazgo. los procesos y entregables
interacciones del sistema.
Adopte la adaptabilidad y la Permitir el cambio para lograr el

Navegar por la complejidad Optimice las respuestas al riesgo estado futuro previsto
resiliencia
Comportamiento de la guía
Partes interesadas
Incertidumbre Equipo
Proyecto Desarrollo
Medición Actuación Acercamiento
y
Dominios
Ciclo vital
Entrega Planificación
trabajo del proyecto
Figura 1-1. Relación entre los Principios de Gestión de Proyectos y los Dominios de Desempeño del Proyecto

Sección 1 Introducción 5
1.3 CAMBIOS A LA GUÍA PMBOK ®
Esta edición de la Guía del PMBOK® se centra en la obtención de resultados independientemente del enfoque utilizado por
el equipo del proyecto. Sin embargo, los profesionales de proyectos que utilizan la Guía PMBOK® también se benefician de cierto
nivel de comprensión sobre cómo entregar proyectos.
Esta edición es muy diferente de los insumos, herramientas/técnicas y productos (OIMT) de ediciones anteriores de
la Guía del PMBOK® . En las ediciones anteriores, la OIMT apoyó la implementación de varios procesos utilizados en la gestión de
proyectos. El cambio de un estándar basado en procesos a uno basado en principios requiere un enfoque diferente para pensar en los
diversos aspectos de la gestión de proyectos. Por lo tanto, los dominios de desempeño del proyecto representan un grupo de
actividades relacionadas que son críticas para la entrega efectiva de los resultados del proyecto. Hay ocho dominios de desempeño
del proyecto en esta guía.
La adaptación es la adaptación deliberada del enfoque, la gobernanza y los procesos de gestión de proyectos para
hacerlos más adecuados para el entorno dado y el trabajo en cuestión. El proceso de adaptación está impulsado por los principios
rectores de la gestión de proyectos, los valores organizacionales y la cultura organizacional.
Al abarcar el espectro completo de enfoques de proyectos, esta edición de la Guía PMBOK®

reconoce que ninguna publicación puede capturar todas las herramientas, técnicas o prácticas que los equipos de proyecto
podrían usar. Por lo tanto, esta edición presenta una variedad de modelos, métodos y artefactos de uso común que los
profesionales de proyectos pueden usar para realizar su trabajo.
1.4 RELACIÓN CON LOS ESTÁNDARES DEL PMI+
La información de esta guía se elabora más en PMIstandards+, la plataforma de contenido digital de PMI.
La plataforma digital abarca prácticas actuales y emergentes y otra información útil
relacionados con la biblioteca de productos de estándares de PMI. También incluye ejemplos prácticos de aplicación dentro
diversos contextos y segmentos de la industria. PMIstandards+ evolucionó en respuesta a los avances y cambios
en cómo se pueden entregar los proyectos. Ofrece un cuerpo dinámico de conocimiento con acceso en tiempo real y
información detallada que está alineada con los estándares de PMI y examinada cuidadosamente por un panel de temas
expertos que representan una amplia gama de conocimientos.

6 Guía PMBOK®
2
Proyecto
Dominios de rendimiento
Un dominio de desempeño del proyecto es un grupo de actividades relacionadas que son críticas para el
entrega de los resultados del proyecto. Los dominios de desempeño del proyecto son áreas de enfoque
interactivas, interrelacionadas e interdependientes que funcionan al unísono para lograr los resultados deseados del
proyecto. Hay ocho dominios de rendimiento del proyecto:
ÿ Partes interesadas,
ÿ Equipo,
ÿ Enfoque de Desarrollo y Ciclo de Vida,
ÿ Planificación,
ÿ Proyecto de Trabajo,
ÿ Entrega,
ÿ Medición, y
ÿ Incertidumbre.
Juntos, los dominios de rendimiento forman un todo unificado. De esta manera, los dominios de desempeño
operar como un sistema integrado, siendo cada dominio de desempeño interdependiente del otro
dominios de desempeño para permitir la entrega exitosa del proyecto y sus resultados previstos.
Los dominios de rendimiento se ejecutan simultáneamente a lo largo del proyecto, independientemente de

cómo se entregue el valor (con frecuencia, periódicamente o al final del proyecto). Por ejemplo, los líderes del proyecto
dedican tiempo a las partes interesadas, el equipo del proyecto, el ciclo de vida del proyecto, el trabajo del proyecto, etc.,
desde el inicio del proyecto hasta su cierre. Estas áreas de enfoque no se abordan como esfuerzos aislados porque se
superponen y se interconectan. Las formas en que se relacionan los dominios de rendimiento son diferentes para cada
proyecto, pero están presentes en todos los proyectos.
Las actividades específicas emprendidas dentro de cada uno de los dominios de desempeño se determinan
por el contexto de la organización, el proyecto, los entregables, el equipo del proyecto, las partes interesadas y
otros factores. Los dominios de desempeño se presentan en las siguientes secciones sin especificar
ponderación u orden.

7
2.1 DOMINIO DE DESEMPEÑO DE LAS PARTES INTERESADAS
DOMINIO DE DESEMPEÑO DE LAS PARTES INTERESADAS
El dominio de La ejecución efectiva de este dominio de desempeño da como resultado

desempeño de las partes los siguientes resultados deseados:
interesadas aborda las Una relación de trabajo productiva con las partes interesadas
actividades y funciones a lo largo del proyecto.
asociadas con las partes interesadas.
Acuerdo de los interesados con los objetivos del proyecto.
Las partes interesadas que son beneficiarios del proyecto lo apoyan y están
satisfechas, mientras que las partes interesadas que pueden oponerse al
proyecto o sus entregables no tienen un impacto negativo en los resultados
del proyecto.
Figura 2-1. Dominio de rendimiento de las partes interesadas
Las siguientes definiciones son relevantes para el dominio de desempeño de las partes interesadas:
Interesado. Un individuo, grupo u organización que puede afectar, ser afectado o percibirse como afectado por una decisión, actividad o resultado
de un proyecto, programa o cartera.
Analisis de los interesados. Un método para recopilar y analizar sistemáticamente información cuantitativa y cualitativa para determinar qué
intereses deben tenerse en cuenta a lo largo del proyecto.

8 Guía PMBOK®
Los proyectos son realizados por personas y para personas. Este dominio de desempeño implica trabajar con las
partes interesadas para mantener la alineación y comprometerse con ellos para fomentar relaciones positivas y satisfacción.
Las partes interesadas incluyen individuos, grupos y organizaciones (consulte la Figura 2-2). Un proyecto puede
tener un pequeño grupo de partes interesadas o potencialmente millones de partes interesadas. Puede haber diferentes
partes interesadas en diferentes fases del proyecto, y la influencia, el poder o los intereses de las partes interesadas pueden
cambiar a medida que se desarrolla el proyecto.
• Proveedores
• Clientes
• Usuarios finales
• Cuerpos reguladores
• Los órganos de gobierno

• PMO
• Comités directivos
• Gerente de proyecto
• Gestión de proyectos
Equipo
• Grupo de proyecto
Figura 2-2. Ejemplos de partes interesadas del proyecto
Sección 2 – Dominios de rendimiento del proyecto 9

La identificación, el análisis y la participación eficaces de las partes interesadas incluyen a las partes interesadas que son
internas y externas a la organización, las que apoyan el proyecto y las que pueden no apoyar o ser neutrales. Si bien tener
habilidades técnicas relevantes de gestión de proyectos es un aspecto importante de los proyectos exitosos, tener las habilidades
interpersonales y de liderazgo para trabajar de manera efectiva con las partes interesadas es igual de importante, si no más.
2.1.1 PARTICIPACIÓN DE LAS PARTES INTERESADAS
La participación de las partes interesadas incluye la implementación de estrategias y acciones para promover la
participación de las partes interesadas. Las actividades de participación de las partes interesadas comienzan antes o cuando
comienza el proyecto y continúan durante todo el proyecto.
Identificar
Monitor Entender
Comprometerse Analizar
priorizar
Figura 2-3. Navegando por la participación efectiva de las partes interesadas

10 Guía PMBOK®
Definir y compartir una visión clara al inicio del proyecto puede permitir buenas relaciones y alineación a lo largo del
proyecto. Establecer una visión clara en la que estén de acuerdo las partes interesadas clave puede implicar algunas negociaciones
desafiantes, especialmente con las partes interesadas que no están necesariamente a favor del proyecto o de los resultados
esperados. Como se muestra en la Figura 2-3, hay varios pasos para involucrar a las partes interesadas de manera efectiva.
2.1.1.1 Identificar
La identificación de las partes interesadas de alto nivel puede llevarse a cabo antes de formar el equipo del proyecto.
La identificación detallada de las partes interesadas elabora progresivamente el trabajo inicial y es una actividad continua a lo largo
del proyecto. Algunas partes interesadas son fáciles de identificar, como el cliente, el patrocinador, el equipo del proyecto, los usuarios
finales, etc., pero otras pueden ser difíciles de identificar cuando no están directamente conectadas con el proyecto.
2.1.1.2 Comprender y analizar

Una vez que se identifican las partes interesadas, el gerente del proyecto y el equipo del proyecto deben buscar
comprender los sentimientos, emociones, creencias y valores de las partes interesadas. Estos elementos pueden generar
amenazas u oportunidades adicionales para los resultados del proyecto. También pueden cambiar rápidamente y, como tal,
comprender y analizar a las partes interesadas es una acción continua.
Relacionado con la comprensión de las partes interesadas del proyecto está la necesidad de analizar aspectos de la
posición y perspectiva de cada parte interesada sobre el proyecto. El análisis de las partes interesadas considera varios aspectos
de las partes interesadas, tales como:
ÿ Poder,
ÿ Impacto,
ÿ Actitud,
ÿ Creencias,
ÿ Expectativas,
ÿ Grado de influencia,
ÿ Proximidad al proyecto,
ÿ Interés en el proyecto, y
ÿ Otros aspectos relacionados con la interacción de los interesados con el proyecto.

Esta información ayuda al equipo del proyecto a considerar las interacciones que pueden influir en las motivaciones,
acciones y comportamientos de las partes interesadas. Además del análisis individual, el equipo del proyecto debe considerar cómo
las partes interesadas interactúan entre sí, ya que a menudo forman alianzas que ayudan o dificultan los objetivos del proyecto. Por
ejemplo, si el equipo del proyecto cree que un gerente comercial clave es muy influyente pero tiene percepciones negativas relacionadas
con el proyecto, pueden explorar cómo detectar las percepciones del gerente comercial y responder adecuadamente a medida que se
desarrolla el proyecto.
En todos los casos, el trabajo de análisis debe ser confidencial para el equipo del proyecto, ya que la información podría malinterpretarse
fuera del contexto del análisis.
2.1.1.3 Priorizar
En muchos proyectos, hay demasiadas partes interesadas involucradas para que el equipo del proyecto participe
directa o efectivamente con todos ellos. Con base en su análisis, el equipo del proyecto puede completar una evaluación inicial
priorización de los interesados. Es común centrarse en las partes interesadas con mayor poder e interés.
como una forma de priorizar el compromiso. A medida que se desarrollan los eventos a lo largo del proyecto, el equipo del proyecto puede
necesidad de volver a priorizar en función de las nuevas partes interesadas o los cambios en evolución en el panorama de las partes interesadas.
2.1.1.4 Participar
La participación de las partes interesadas implica trabajar en colaboración con las partes interesadas para presentar el
proyecto, obtener sus requisitos, gestionar las expectativas, resolver problemas, negociar, priorizar, resolver problemas y tomar decisiones.
Involucrar a las partes interesadas requiere la aplicación de habilidades blandas, como la escucha activa, las habilidades interpersonales y
la gestión de conflictos, así como habilidades de liderazgo, como establecer la visión y el pensamiento crítico.
La comunicación con las partes interesadas puede tener lugar por medios escritos o verbales, y puede ser
formal o informal. En la Tabla 2-1 se muestran ejemplos de cada tipo de comunicación.

12 Guía PMBOK®
Tabla 2-1. Tipos de comunicación
Tipo Formal Informal
Verbal Presentaciones Conversaciones
Revisiones de proyectos Debates ad hoc
Sesiones informativas
demostraciones de productos
Lluvia de ideas
Escrito Reporte de progreso Notas breves
Documentos del proyecto Correo electrónico
Caso de negocio Mensajería instantánea/mensajes de texto
Medios de comunicación social
Los métodos de comunicación incluyen push, pull y comunicación interactiva:
ÿ Empuje. Comunicación enviada a las partes interesadas, como memorandos, correos electrónicos, informes de estado,
correo de voz, etc. La comunicación push se utiliza para comunicaciones unidireccionales con partes interesadas
individuales o grupos de partes interesadas. La comunicación de empuje inhibe la capacidad de medir inmediatamente la
reacción y evaluar la comprensión; por lo tanto, debe usarse deliberadamente.
ÿ Tire. Información buscada por la parte interesada, como un miembro del equipo del proyecto que va a un
intranet para encontrar políticas o plantillas de comunicación, realizar búsquedas en Internet y usar repositorios en línea. La
extracción de información se utiliza para la detección indirecta de las preocupaciones de las partes interesadas.
El compromiso va más allá de empujar o jalar la comunicación. El compromiso es interactivo.

Incluye un intercambio de información con una o más partes interesadas, como conversaciones, llamadas telefónicas, reuniones, intercambio
de ideas, demostraciones de productos y similares.
Con todas las formas de comunicación, los bucles de retroalimentación rápidos brindan información útil para:
ÿ Confirme el grado en que las partes interesadas escucharon el mensaje.
ÿ Determine si las partes interesadas están de acuerdo con el mensaje.
ÿ Identifique los mensajes matizados u otros mensajes no deseados que detectó el destinatario.
ÿ Obtenga otros conocimientos útiles.

2.1.1.5 Supervisar
A lo largo del proyecto, los interesados cambiarán a medida que se identifiquen nuevos interesados y otros dejen de
serlo. A medida que avanza el proyecto, la actitud o el poder de algunos interesados puede cambiar. Además de identificar y
analizar nuevas partes interesadas, existe la oportunidad de evaluar si la estrategia de participación actual es efectiva o si
necesita ser ajustada. Por lo tanto, la cantidad y la eficacia de la participación de las partes interesadas se monitorean a lo
largo del proyecto.
El grado de satisfacción de las partes interesadas a menudo se puede determinar manteniendo una conversación con
las partes interesadas para medir su satisfacción con los entregables del proyecto y la gestión general del proyecto. Las
revisiones de proyectos e iteraciones, las revisiones de productos, las puertas de etapas y otros métodos son formas de
obtener comentarios periódicos. Para grandes grupos de partes interesadas, se puede utilizar una encuesta para evaluar el
grado de satisfacción. Cuando sea necesario, el enfoque de participación de las partes interesadas se puede actualizar para
lograr una mayor satisfacción de las partes interesadas.
2.1.2 INTERACCIONES CON OTROS DOMINIOS DE RENDIMIENTO
Las partes interesadas impregnan todos los aspectos del proyecto. Definen y priorizan los requisitos
y alcance para el equipo del proyecto. Participan y dan forma a la planificación. Determinan los criterios de
aceptación y calidad para los entregables y resultados del proyecto. Gran parte del trabajo del proyecto gira en torno a la
participación y la comunicación con las partes interesadas. A lo largo del proyecto o al cierre, utilizan los entregables del
proyecto e influyen en la realización de los resultados del proyecto.
Algunas partes interesadas pueden ayudar a reducir la cantidad de incertidumbre presente en un proyecto, mientras
que otras pueden causar un aumento de la incertidumbre. Las partes interesadas, como los clientes, la alta dirección, los
líderes de la oficina de gestión de proyectos o los directores de programas, se centrarán en las medidas de rendimiento del
proyecto y sus entregables. Estas interacciones son ejemplos de cómo el dominio de desempeño de las partes interesadas se
integra y entrelaza con otros dominios de desempeño, aunque no incluyen todas las formas en que las preocupaciones de las
partes interesadas interactúan en los dominios de desempeño.

14 Guía PMBOK®
2.1.3 COMPROBACIÓN DE RESULTADOS
La Tabla 2-2 identifica los resultados a la izquierda y las formas de verificarlos a la derecha.
Tabla 2-2. Verificación de resultados: dominio de desempeño de las partes interesadas
Salir Cheque
Una relación de trabajo productiva con las Se pueden observar relaciones productivas de trabajo con las partes interesadas. Sin embargo,
partes interesadas a lo largo del proyecto. el movimiento de las partes interesadas a lo largo de un continuo de compromiso puede indicar el nivel relativo
de satisfacción con el proyecto.
Acuerdo de las partes interesadas con los objetivos Un número significativo de cambios o modificaciones a los requisitos del proyecto y del producto además
del proyecto del alcance pueden indicar que las partes interesadas no están comprometidas o alineadas con los objetivos
del proyecto.
Los interesados que son beneficiarios El comportamiento de los interesados puede indicar si los beneficiarios del proyecto están satisfechos y lo
del proyecto lo apoyan y están apoyan o si se oponen a él. Las encuestas, las entrevistas y los grupos focales también son formas efectivas
satisfechos; las partes interesadas que de determinar si las partes interesadas están satisfechas y brindan apoyo o si se oponen al proyecto y sus
pueden oponerse al proyecto o sus entregables.
entregables no tienen un impacto negativo
Una revisión del registro de problemas y el registro de riesgos del proyecto puede identificar los desafíos
en los resultados del proyecto asociados con las partes interesadas individuales.

2.2 DOMINIO DE RENDIMIENTO DEL EQUIPO
DOMINIO DE RENDIMIENTO DEL EQUIPO
El Dominio de Desempeño La ejecución efectiva de este dominio de desempeño da como resultado los
del Equipo aborda las siguientes resultados deseados:
actividades y funciones
Propiedad compartida.
asociadas con las personas
Un equipo de alto rendimiento.
que son responsables de
Liderazgo aplicable y otras habilidades interpersonales
producir los entregables del
demostrado por todos los miembros del equipo.
proyecto que logran los
resultados comerciales.
Figura 2-4. Dominio de rendimiento del equipo
Este dominio de rendimiento implica establecer la cultura y el entorno que permite que una colección de personas diversas se convierta
en un equipo de proyecto de alto rendimiento. Esto incluye reconocer las actividades necesarias para fomentar el desarrollo del equipo del proyecto
y alentar los comportamientos de liderazgo de todos los miembros del equipo del proyecto.
Las siguientes definiciones son relevantes para el dominio de rendimiento del equipo:
Gerente de proyecto. La persona asignada por la organización ejecutora para liderar el equipo del proyecto que es responsable de lograr los objetivos
del proyecto.
Equipo de gestión de proyectos. Los miembros del equipo del proyecto que están directamente involucrados en las actividades de gestión del proyecto.
Grupo de proyecto. Un conjunto de individuos que realizan el trabajo del proyecto para lograr sus objetivos.

dieciséis Guía PMBOK®
2.2.1 GESTIÓN Y LIDERAZGO DEL EQUIPO DEL PROYECTO
La gestión de proyectos implica la aplicación de conocimientos, habilidades, herramientas y técnicas para la gestión
actividades, así como actividades de liderazgo. Las actividades de gestión se enfocan en los medios para cumplir
con los objetivos del proyecto, tales como tener procesos efectivos, planificar, coordinar, medir y monitorear el
trabajo, entre otros. Las actividades de liderazgo se centran en las personas. El liderazgo incluye influir, motivar,
escuchar, habilitar y otras actividades que tienen que ver con el equipo del proyecto.
Ambos son importantes para lograr los resultados esperados.
2.2.1.1 Gestión y liderazgo centralizados

Mientras que las actividades de liderazgo deben ser practicadas por todos los miembros del equipo del proyecto,
las actividades de gestión pueden centralizarse o distribuirse. En un entorno donde las actividades de gestión están
centralizadas, la rendición de cuentas (ser responsable de un resultado) generalmente se asigna a una persona, como el
director del proyecto o un rol similar. En estas situaciones, un acta de constitución del proyecto u otro documento de
autorización puede proporcionar la aprobación para que el gerente del proyecto forme un equipo de proyecto para lograr los
resultados del proyecto.
2.2.1.2 Gestión y Liderazgo Distribuidos

A veces, las actividades de gestión de proyectos se comparten entre un equipo de gestión de proyectos y los
miembros del equipo del proyecto son responsables de completar el trabajo. También hay situaciones en las que un equipo
de proyecto puede autoorganizarse para completar un proyecto. En lugar de tener un gerente de proyecto designado, alguien
dentro del equipo del proyecto puede servir como facilitador para permitir la comunicación, la colaboración y el compromiso.
Este rol puede cambiar entre los miembros del equipo del proyecto.
El liderazgo de servicio es un estilo de liderazgo que se enfoca en comprender y abordar las necesidades y el
desarrollo de los miembros del equipo del proyecto para permitir el mayor rendimiento posible del equipo del proyecto.
Los líderes de servicio ponen énfasis en desarrollar a los miembros del equipo del proyecto a su máximo potencial al
enfocarse en abordar preguntas, tales como:
ÿ ¿Los miembros del equipo del proyecto están creciendo como individuos?
ÿ ¿Los miembros del equipo del proyecto se están volviendo más saludables, más sabios, más libres y más autónomos?
ÿ ¿Es más probable que los miembros del equipo del proyecto se conviertan en líderes servidores?

Los líderes de servicio permiten que los equipos de proyecto se organicen por sí mismos cuando sea posible y aumentan
los niveles de autonomía al pasar las oportunidades apropiadas de toma de decisiones a los miembros del equipo de proyecto. Los
comportamientos de liderazgo de servicio incluyen:
ÿ Eliminación de obstáculos. Dado que es el equipo del proyecto quien genera la mayoría de los negocios
valor, un papel crítico para el líder de servicio es maximizar la entrega eliminando los impedimentos para su progreso. Esto
incluye resolver problemas y eliminar obstáculos que puedan estar obstaculizando el trabajo del equipo del proyecto. Al resolver
o aliviar estos impedimentos, el equipo del proyecto puede entregar valor al negocio más rápido.
ÿ Escudo de desvío. Los líderes servidores protegen al equipo del proyecto de ataques internos y externos.
desviaciones que redirigen al equipo del proyecto de los objetivos actuales. La fragmentación del tiempo reduce la
productividad, por lo que proteger al equipo del proyecto de demandas externas no críticas ayuda al equipo del proyecto a
mantenerse enfocado.
ÿ Oportunidades de estímulo y desarrollo. El líder servidor también proporciona

herramientas y aliento para mantener al equipo del proyecto satisfecho y productivo. Aprender lo que motiva a los miembros
del equipo del proyecto como individuos y encontrar formas de recompensarlos por un buen trabajo ayuda a mantener
satisfechos a los miembros del equipo del proyecto.
2.2.1.3 Aspectos comunes del desarrollo del equipo
Independientemente de cómo se estructuren las actividades de gestión, existen aspectos comunes

del desarrollo del equipo de proyecto que son relevantes para la mayoría de los equipos de proyecto. Éstos incluyen:
ÿ Visión y objetivos. Es fundamental que todos conozcan la visión y los objetivos del proyecto. La visión y los objetivos se
comunican a lo largo del proyecto. Esto incluye hacer referencia a los resultados previstos cuando el equipo del proyecto
participa en la toma de decisiones y la resolución de problemas.
ÿ Roles y responsabilidades. Es importante asegurarse de que los miembros del equipo del proyecto
comprender y cumplir sus funciones y responsabilidades. Esto puede incluir la identificación de brechas en el
conocimiento y las habilidades, así como estrategias para abordar esas brechas a través de capacitación, tutoría o
entrenamiento.

18 Guía PMBOK®
ÿ Operaciones del equipo de proyecto. Facilitar la comunicación del equipo del proyecto, la resolución de problemas y la
el proceso de llegar a un consenso puede incluir trabajar con el equipo del proyecto para desarrollar
un estatuto del equipo del proyecto y un conjunto de pautas operativas o normas del equipo del proyecto.
ÿ Orientación. La orientación se puede dirigir al equipo general del proyecto para mantener a todos enfocados
en la dirección correcta. Los miembros individuales del equipo del proyecto también pueden proporcionar orientación sobre
una tarea o entrega particular.
ÿ Crecimiento. Identificar áreas en las que el equipo del proyecto se está desempeñando bien y señalar áreas
donde el equipo del proyecto puede mejorar ayuda al equipo del proyecto a crecer. Trabajando en colaboración,
el equipo del proyecto puede identificar objetivos para su mejora y tomar medidas para alcanzar esos objetivos.
Esto también se aplica a cada individuo en el equipo del proyecto. Las personas pueden querer hacer crecer su
habilidades y experiencia en ciertas áreas, y el director del proyecto puede ayudar con eso.
Hay varios modelos que describen las etapas de crecimiento del equipo del proyecto incluidos en la Sección 4.
Cuando los equipos de proyecto se forman en diferentes organizaciones en función de un contrato, una asociación estratégica
u otra relación comercial, los roles específicos que realizan varias funciones pueden estar más formalizados y menos flexibles según el
contrato u otros términos. Dichos arreglos a menudo requieren más trabajo por adelantado para establecer una mentalidad de "un equipo",
garantizar que los miembros del equipo del proyecto entiendan cómo todos contribuyen al proyecto y establecer otros habilitadores que
integren habilidades, capacidades y procesos.

2.2.2 CULTURA DEL EQUIPO DEL PROYECTO
Cada equipo de proyecto desarrolla su propia cultura de equipo. La cultura del equipo del proyecto puede establecerse
deliberadamente mediante el desarrollo de normas del equipo del proyecto, o de manera informal a través de los comportamientos y
acciones de los miembros del equipo del proyecto. La cultura del equipo del proyecto opera dentro de la cultura de la organización,
pero refleja las formas individuales de trabajar e interactuar del equipo del proyecto.
Los seres humanos tenemos una serie de sesgos, algunos de ellos inconscientes y otros conscientes.
Por ejemplo, una persona puede sentir que, a menos que se muestre un cronograma usando un diagrama de Gantt generado por
software, no es un cronograma verdadero o válido. Otra persona puede tener un sesgo contrastante de que la planificación
detallada más allá de los 30 días es una pérdida de tiempo. Ser abierto y transparente sobre los prejuicios desde el principio
establece una cultura de apertura y confianza que puede permitir el consenso y la colaboración.
El director del proyecto es clave para establecer y mantener un entorno seguro, respetuoso y sin prejuicios que permita al
equipo del proyecto comunicarse abiertamente. Una forma de lograr esto es modelando los comportamientos deseados, como:
ÿ Transparencia. Ser transparente en cómo uno piensa, toma decisiones y procesa

la información ayuda a otros a identificar y compartir sus propios procesos. Esto puede extenderse a ser
transparente acerca de los sesgos también.
ÿ Integridad. La integridad se compone de comportamiento ético y honestidad. Individuos

demostrar honestidad sacando a la luz los riesgos, comunicando sus supuestos y fundamentos
de estimaciones, entregando malas noticias temprano, asegurando que los informes de estado proporcionen una información precisa
descripción del estado del proyecto, y de muchas otras maneras. El comportamiento ético puede incluir
sacar a la superficie posibles defectos o efectos negativos en el diseño del producto, revelar posibles
conflictos de intereses, garantizar la equidad y tomar decisiones basadas en criterios ambientales,
partes interesadas e impactos financieros.

20 Guía PMBOK®
ÿ Respeto. Demostrar respeto por cada persona, cómo piensa la persona, las habilidades de la persona y la
perspectiva y la experiencia que la persona aporta al equipo del proyecto prepara el escenario para que todos
los miembros del equipo del proyecto adopten este comportamiento.
ÿ Discurso positivo. A lo largo del proyecto, diversas opiniones, diferentes formas de

situaciones que se aproximan, y se producirán malentendidos. Estos son una parte normal de la realización de
proyectos. Presentan una oportunidad para tener un diálogo en lugar de un debate.
Un diálogo implica trabajar con otros para resolver opiniones divergentes. El objetivo es llegar a una resolución que
todas las partes puedan adoptar. Un debate, por otro lado, es un escenario de ganar-perder donde las personas
están más interesadas en ganar personalmente que en estar abiertas a soluciones alternativas a un problema.
ÿ Soporte. Los proyectos pueden ser desafiantes desde la perspectiva de los desafíos técnicos, las influencias
ambientales y las interacciones interpersonales. Apoyar a los miembros del equipo del proyecto a través de
la resolución de problemas y la eliminación de impedimentos crea una cultura de apoyo y conduce a un entorno de
confianza y colaboración. El apoyo también se puede demostrar brindando aliento, mostrando empatía y participando
en una escucha activa.
ÿ Coraje. Recomendar un nuevo enfoque para un problema o una forma de trabajar puede ser
intimidante Del mismo modo, puede ser un desafío estar en desacuerdo con un experto en la materia o con
alguien con mayor autoridad. Sin embargo, demostrar el coraje que se necesita para hacer una sugerencia, estar en
desacuerdo o probar algo nuevo permite una cultura de experimentación y comunica a los demás que es seguro ser
valiente y probar nuevos enfoques.
ÿ Celebrando el éxito. Centrarse en los objetivos, desafíos y problemas del proyecto a menudo deja de lado
el hecho de que los miembros individuales del equipo del proyecto y el equipo del proyecto como un todo estén
progresando constantemente hacia esas metas. Debido a que el trabajo tiene prioridad, los miembros del equipo del
proyecto pueden aplazar el reconocimiento de demostraciones de innovación, adaptación, servicio a los demás y aprendizaje.
Sin embargo, reconocer dichas contribuciones en tiempo real puede mantener motivados al equipo del
proyecto ya las personas.

2.2.3 EQUIPOS DE PROYECTO DE ALTO RENDIMIENTO
Uno de los objetivos del liderazgo eficaz es crear un equipo de proyecto de alto rendimiento. Hay un numero
de factores que contribuyen a equipos de proyecto de alto rendimiento. La lista a continuación no es exhaustiva, pero identifica
algunos de los factores asociados con los equipos de proyecto de alto rendimiento.
ÿ Comunicación abierta. Un entorno que fomenta la comunicación abierta y segura

permite reuniones productivas, resolución de problemas, intercambio de ideas, etc. También es la piedra angular de
otros factores, como la comprensión compartida, la confianza y la colaboración.
ÿ Comprensión compartida. El propósito del proyecto y los beneficios que proporcionará son
celebrada en común.
ÿ Propiedad compartida. Cuanto más propiedad de los resultados sientan los miembros del equipo del proyecto,
mejor será su desempeño.
ÿ Confianza. Un equipo de proyecto en el que sus miembros confían unos en otros está dispuesto a hacer un esfuerzo
adicional para lograr el éxito. Es menos probable que las personas hagan el trabajo adicional que se necesita para
tener éxito si no confían en los miembros del equipo del proyecto, el gerente del proyecto o la organización.
ÿ Colaboración. Los equipos de proyecto que colaboran y trabajan entre sí en lugar de trabajar en silos o competir
tienden a generar ideas más diversas y terminan con mejores resultados.
ÿ Adaptabilidad. Equipos de proyecto que pueden adaptar su forma de trabajar al entorno.

y la situación son más eficaces.
ÿ Resiliencia. Cuando ocurren problemas o fallas, los equipos de proyecto de alto rendimiento se recuperan rápidamente.
ÿ Empoderamiento. Los miembros del equipo del proyecto que se sienten empoderados para tomar decisiones sobre la
forma en que trabajan se desempeñan mejor que aquellos que están microgestionados.
ÿ Reconocimiento. Equipos de proyecto que son reconocidos por el trabajo que realizan y la
el desempeño que logran tienen más probabilidades de continuar desempeñándose bien. Incluso el simple acto
de mostrar aprecio refuerza el comportamiento positivo del equipo.

22 Guía PMBOK®
2.2.4 HABILIDADES DE LIDERAZGO
Las habilidades de liderazgo son útiles para todos los miembros del equipo del proyecto, ya sea que el equipo del proyecto esté operando
en un entorno con una autoridad centralizada o un entorno de liderazgo compartido. Las siguientes secciones describen
algunas de las características y actividades asociadas con el liderazgo.
2.2.4.1 Establecimiento y mantenimiento de la visión
Todo proyecto tiene un propósito. Comprender ese propósito es fundamental para que las personas dediquen
su tiempo y energía en la dirección correcta para lograr el propósito del proyecto. La visión del proyecto resume el propósito
del proyecto de forma clara y sucinta. Describe una visión realista y atractiva de los resultados futuros del proyecto.
Además de describir brevemente el estado futuro deseado, la visión es una poderosa herramienta de motivación.
Es una forma de crear pasión y significado para el objetivo previsto de un proyecto. Una visión común ayuda a que las
personas sigan avanzando en la misma dirección. Cuando se sumerge en los detalles del trabajo diario, una comprensión
clara del objetivo final puede ayudar a guiar las decisiones locales hacia el resultado deseado del proyecto.
Una visión desarrollada en colaboración entre los miembros del equipo del proyecto y las partes interesadas clave debe
responder a estas preguntas:
ÿ ¿Cuál es el propósito del proyecto?
ÿ ¿Qué define un trabajo de proyecto exitoso?
ÿ ¿Cómo será mejor el futuro cuando se entreguen los resultados del proyecto?
ÿ ¿Cómo sabrá el equipo del proyecto que se está desviando de la visión?
Una buena visión es clara, concisa y procesable. Hace lo siguiente:
ÿ Resume el proyecto con una frase poderosa o una breve descripción,
ÿ Describe el mejor resultado alcanzable,
ÿ Crea una imagen común y cohesiva en la mente de los miembros del equipo del proyecto, y
ÿ Inspira pasión por el resultado.

2.2.4.2 Pensamiento crítico

A lo largo de los diversos dominios de desempeño del proyecto, existe la necesidad de reconocer el sesgo,
identificar la causa raíz de los problemas y considerar cuestiones desafiantes, como la ambigüedad, la complejidad, etc.
El pensamiento crítico ayuda a realizar estas actividades. El pensamiento crítico incluye un pensamiento disciplinado,
racional, lógico y basado en la evidencia. Requiere una mente abierta y la capacidad de analizar objetivamente. El
pensamiento crítico, especialmente cuando se aplica al descubrimiento, puede incluir imaginación conceptual, perspicacia
e intuición. También puede incluir el pensamiento reflexivo y la metacognición (pensar sobre el pensamiento y ser
consciente de la propia conciencia).
Los miembros del equipo del proyecto aplican el pensamiento crítico a:
ÿ Investigar y recopilar información imparcial y bien equilibrada;
ÿ Reconocer, analizar y resolver problemas;
ÿ Identificar sesgos, suposiciones no declaradas y valores;
ÿ Discernir el uso del lenguaje y la influencia sobre uno mismo y los demás;
ÿ Analizar datos y pruebas para evaluar argumentos y perspectivas;
ÿ Observar eventos para identificar patrones y relaciones;
ÿ Aplicar el razonamiento inductivo, deductivo y abductivo de manera adecuada; y
ÿ Identificar y articular premisas falsas, analogías falsas, apelaciones emocionales y otra lógica defectuosa.
2.2.4.3 Motivación
Motivar a los miembros del equipo del proyecto tiene dos aspectos: el primero es comprender qué motiva a los
miembros del equipo del proyecto a desempeñarse y el segundo es trabajar con los miembros del equipo del proyecto
de tal manera que permanezcan comprometidos con el proyecto y sus resultados.
La motivación para realizar puede ser intrínseca o extrínseca. La motivación intrínseca proviene del interior del
individuo o está asociada al trabajo. Se asocia con encontrar placer en el trabajo en sí mismo en lugar de centrarse en
las recompensas. La motivación extrínseca es realizar un trabajo debido a una recompensa externa, como una bonificación.
Gran parte del trabajo realizado en los proyectos está alineado con la motivación intrínseca.

24 Guía PMBOK®
Ejemplos de factores de motivación intrínsecos incluyen:
ÿ Logro,
ÿ Desafío,
ÿ Creencia en el trabajo,
ÿ Haciendo la diferencia,
ÿ Autodirección y autonomía,
ÿ Responsabilidad,
ÿ Crecimiento personal,
ÿ Relación, y
ÿ Formar parte de un equipo de proyecto.
Las personas no están motivadas por una sola cosa; sin embargo, la mayoría de las personas tienen un motivador dominante.
Para motivar efectivamente a los miembros del equipo del proyecto, es útil conocer el motivador dominante de cada
miembro. Por ejemplo, un miembro del equipo de proyecto que está motivado por el desafío responderá bien a los objetivos
ambiciosos y los problemas que debe resolver. Un miembro del equipo del proyecto que está motivado por la relación
responderá a ser parte de un grupo de trabajo dinámico. Los miembros del equipo del proyecto que disfrutan de la autonomía
se desempeñarán mejor si pueden establecer sus propias formas de trabajo e incluso sus propias horas y cadencia de
trabajo. Por lo tanto, adaptar los métodos de motivación en función de las preferencias individuales ayuda a obtener el mejor
desempeño individual y del equipo del proyecto.
2.2.4.4 Habilidades interpersonales
Las habilidades interpersonales que se utilizan con frecuencia en los proyectos incluyen inteligencia emocional, decisión
elaboración y resolución de conflictos, entre otros.
ÿ Inteligencia emocional. La inteligencia emocional es la capacidad de reconocer nuestras propias emociones

y los de los demás. Esta información se utiliza para guiar el pensamiento y el comportamiento. Reconocimiento de
Los sentimientos personales, la empatía por los sentimientos de los demás y la capacidad de actuar adecuadamente son
las piedras angulares para una comunicación, colaboración y liderazgo efectivos.

Dado que los proyectos son realizados por personas y para personas, la inteligencia emocional, la capacidad de
comprenderse a sí mismo y mantener relaciones de trabajo efectivas con los demás, es fundamental en los entornos
de los equipos de proyectos.
Existen múltiples modelos para definir y explicar la inteligencia emocional. Convergen en cuatro áreas clave:
ÿ Autoconocimiento. La autoconciencia es la capacidad de realizar una autoevaluación realista.

Incluye comprender nuestras propias emociones, metas, motivaciones, fortalezas y
debilidades
ÿ Autogestión. La autogestión, también conocida como autorregulación, es la capacidad de

controlar y redirigir sentimientos e impulsos perturbadores. Es la capacidad de pensar antes
actuar, suspendiendo los juicios precipitados y las decisiones impulsivas.
ÿ Conciencia social. La conciencia social tiene que ver con la empatía y la comprensión y
teniendo en cuenta los sentimientos de otras personas. Esto incluye la capacidad de leer señales no verbales
y lenguaje corporal.
ÿ Habilidad social. La habilidad social es la culminación de las otras dimensiones de la emocionalidad.

inteligencia. Se ocupa de la gestión de grupos de personas, como equipos de proyectos,
construyendo redes sociales, encontrando puntos en común con varias partes interesadas, y
construir buenas relaciones.
Se requiere autoconciencia y autogestión para mantener la calma y la productividad durante las circunstancias
difíciles del proyecto. La conciencia social y las habilidades sociales permiten mejores vínculos con los miembros del equipo del
proyecto y las partes interesadas del proyecto. La inteligencia emocional es la base de todas las formas de liderazgo.
La figura 2-5 muestra los puntos clave de cada uno de los cuatro aspectos de la inteligencia emocional y cómo se
relacionan. Los aspectos que tienen que ver con uno mismo están arriba y los aspectos sociales están abajo. La conciencia está
en el lado izquierdo, y la gestión y la habilidad están en el lado derecho.

26 Guía PMBOK®
Conciencia de sí mismo Autogestión

• ¿Cómo afecta al • Piensa antes de actuar
equipo?
• Generar confianza
• ¿Cómo te afecta el
equipo?
Conciencia social Habilidades sociales
• Sea empático • • Establecer una buena
Emplee la escucha relación • Construir equipos
activa efectivos
• Manejar la actitud
Figura 2-5. Componentes de la Inteligencia Emocional
Algunos modelos de inteligencia emocional incluyen una quinta área para la motivación. motivación en este
El contexto se trata de comprender lo que impulsa e inspira a las personas.
ÿ Toma de decisiones. Los gerentes de proyecto y los equipos de proyecto toman muchas decisiones
diariamente. Algunas decisiones pueden ser bastante intrascendentes para el resultado del proyecto,
como dónde ir para un almuerzo de equipo, y otras tendrán un gran impacto, como qué enfoque de
desarrollo usar, qué herramienta usar o qué proveedor seleccionar.

Las decisiones pueden tomarse unilateralmente. Esto tiene la ventaja de ser rápido, pero es propenso a errores en
comparación con la participación de la sabiduría de un conjunto diverso de personas. La toma de decisiones unilateral
también puede desmotivar a las personas que se ven afectadas por la decisión, ya que pueden sentir que no se tuvieron
en cuenta sus opiniones y preocupaciones.
La toma de decisiones en grupo tiene la ventaja de aprovechar la amplia base de conocimientos de un grupo. Involucrar
a las personas en el proceso de toma de decisiones también aumenta la aceptación del resultado, incluso si la opción
seleccionada puede no haber sido la primera opción de todos. Generalmente, la inclusión aumenta el compromiso con la
decisión. La desventaja de la toma de decisiones en grupo es el tiempo requerido y la interrupción del trabajo en equipo que
puede ocurrir cuando las personas se retiran de su trabajo para ser consultadas en una decisión.
La toma de decisiones del equipo del proyecto a menudo sigue un patrón de divergencia/convergencia. Esto
significa que las partes interesadas primero se comprometen a generar un amplio conjunto de alternativas o enfoques de solución.
A menudo, esto se hace individualmente para evitar el efecto de que las partes interesadas de alto nivel o carismáticas influyan
indebidamente en otras partes interesadas. Luego, después de que se haya generado un amplio espectro de alternativas de
decisión, el equipo del proyecto converge en una solución preferida.
El objetivo es tomar decisiones rápidamente mientras se involucra el conocimiento diverso de un grupo de manera inclusiva
y respetuosa. Algunas decisiones pueden tomarse en una dirección diferente a la que prefieren algunas personas, pero
todos tienen la oportunidad de explicar su posición. Al final, la autoridad decisoria, ya sea un individuo o un grupo, toma una
decisión basada en el análisis presentado y teniendo en cuenta las expectativas de las partes interesadas.
La selección cuidadosa de las decisiones que deben someterse a discusión y votación en grupo limita las interrupciones
y el cambio de tareas experimentado por el equipo del proyecto. Muchos enfoques, como la votación romana, la estimación
Delphi de banda ancha y la votación de puño de cinco, utilizan el método diverge/
patrón de convergencia. Su objetivo es involucrar la participación individual mientras se vota en el mismo momento, lo que
minimiza el pensamiento grupal.
Para aquellas decisiones que están más allá de la autoridad del equipo del proyecto para decidir, el equipo del proyecto
puede investigar alternativas, considerar los impactos de cada alternativa y escalar la decisión a alguien con la autoridad
adecuada. Este proceso se alinea con la filosofía de “no me traigas problemas, tráeme soluciones”, sin dejar de estar alineado
con la gobernanza organizacional con respecto a la autoridad para la toma de decisiones.

28 Guía PMBOK®
ÿ Gestión de conflictos. El conflicto ocurre en todos los proyectos. Los proyectos operan en entornos dinámicos y
enfrentan muchas restricciones mutuamente excluyentes, incluido el presupuesto, el alcance, el cronograma y la
calidad, que pueden generar conflictos. No es raro querer evitar el conflicto, pero no todo conflicto es negativo. La
forma en que se maneja el conflicto puede generar más conflicto o una mejor toma de decisiones y soluciones
más sólidas.
Abordar el conflicto antes de que se intensifique más allá del debate útil conduce a mejores resultados.
Los siguientes enfoques pueden ayudar:
ÿ Mantenga las comunicaciones abiertas y respetuosas. Debido a que el conflicto puede causar ansiedad, es
importante mantener un ambiente seguro para explorar la fuente del conflicto. Sin un entorno seguro, las personas
dejarán de comunicarse. Asegúrese de que las palabras, el tono de voz y el lenguaje corporal no sean
amenazantes.
ÿ Concéntrese en los problemas, no en las personas. El conflicto se basa en que las personas perciben las
situaciones de manera diferente. No debe ser personal. La atención se centra en resolver la situación, no en
culpar.
ÿ Centrarse en el presente y el futuro, no en el pasado. Manténgase enfocado en la situación actual,

no situaciones pasadas. Si algo similar sucedió anteriormente, sacar a relucir el pasado no resolverá la situación
actual. De hecho, puede servir para intensificar la situación actual.
aún más.
ÿ Buscar alternativas juntos. Los daños ocasionados por un conflicto pueden repararse
buscando juntos soluciones y alternativas. También puede crear relaciones más constructivas. Esto traslada el
conflicto a un espacio más de resolución de problemas donde las personas pueden trabajar juntas para generar
alternativas creativas.
Existen varios modelos para abordar y resolver conflictos. Algunos de ellos son discutidos
en la Sección 4.

2.2.5 ESTILOS DE LIDERAZGO A LA MEDIDA
Al igual que con todos los aspectos de los proyectos, los estilos de liderazgo también se adaptan para satisfacer
las necesidades del proyecto, el entorno y las partes interesadas. Algunas de las variables que influyen en la adaptación
de los estilos de liderazgo incluyen:
ÿ Experiencia con el tipo de proyecto. Las organizaciones y los equipos de proyecto con experiencia en un tipo
específico de proyecto pueden ser más autogestionarios y requerir menos liderazgo. Cuando un proyecto es nuevo
para una organización, la tendencia es proporcionar más supervisión y utilizar un estilo de liderazgo más directivo.
ÿ Madurez de los miembros del equipo del proyecto. Los miembros del equipo del proyecto que son maduros en el
campo técnico pueden necesitar menos supervisión y dirección que los miembros del equipo del proyecto que son
nuevos en la organización, el equipo o la especialidad técnica.
ÿ Estructuras de gobierno organizacional. Los proyectos operan dentro de un sistema organizacional más grande.
Puede existir la expectativa de que el estilo de liderazgo organizacional de la alta dirección sea reconocido y
reflejado en el liderazgo del equipo. La estructura organizativa influye en el grado en que se centralizan o
distribuyen la autoridad y la rendición de cuentas.
ÿ Equipos de proyecto distribuidos. Una fuerza laboral de proyecto global es más común hoy que en el pasado. A
pesar de los mejores esfuerzos para conectar a las personas virtualmente, puede ser un desafío crear el mismo nivel
de colaboración y relación que se logra cuando se trabaja cara a cara.
Para minimizar las trampas de los equipos de proyectos distribuidos, la tecnología se puede utilizar para
aumentar y mejorar la comunicación. Ejemplos incluyen:
ÿ Asegúrese de que haya sitios de colaboración para trabajar juntos.
ÿ Tenga un sitio de equipo de proyecto para mantener todos los proyectos relevantes y el equipo de proyecto
información disponible.
ÿ Use capacidades de audio y video para reuniones.
ÿ Usar la tecnología para mantener un contacto continuo, como mensajes y mensajes de texto.
ÿ Incorpore tiempo para conocer a los miembros remotos del equipo del proyecto.
ÿ Tener al menos una reunión cara a cara para establecer relaciones.

30 Guía PMBOK®

El dominio de desempeño del equipo enfatiza las habilidades utilizadas por los gerentes de proyecto y los miembros
del equipo del proyecto a lo largo del proyecto. Estas habilidades están entretejidas en todos los demás aspectos del proyecto.
Se pide a los miembros del equipo del proyecto que demuestren cualidades y habilidades de liderazgo a lo largo del
proyecto. Comunicar la visión y los beneficios del proyecto a las partes interesadas durante la planificación y durante
todo el ciclo de vida es un ejemplo. Otro ejemplo es el empleo del pensamiento crítico, la resolución de problemas y la toma
de decisiones al participar en el trabajo del proyecto. La rendición de cuentas por los resultados se demuestra en todos los
dominios de rendimiento de planificación y medición.
2.2.7 COMPROBACIÓN DE RESULTADOS
La Tabla 2-3 identifica los resultados de la aplicación efectiva del Dominio de Desempeño del Equipo
a la izquierda y formas de comprobarlos a la derecha.
Tabla 2-3. Comprobación de resultados: dominio de rendimiento del equipo
Salir Cheque
Propiedad compartida Todos los miembros del equipo del proyecto conocen la visión y los objetivos. El equipo del proyecto
posee los entregables y los resultados del proyecto.
Un equipo de alto rendimiento El equipo del proyecto confía el uno en el otro y colabora. El equipo del proyecto se adapta a las situaciones
cambiantes y es resiliente ante los desafíos. El equipo del proyecto se siente empoderado y empodera y
reconoce a los miembros del equipo del proyecto.
Todos los miembros del equipo del proyecto Los miembros del equipo del proyecto aplican el pensamiento crítico y las habilidades interpersonales.
demuestran liderazgo aplicable y otras habilidades Los estilos de liderazgo de los miembros del equipo del proyecto son apropiados para el contexto y el
interpersonales. entorno del proyecto.

2.3 ENFOQUE DE DESARROLLO Y CICLO DE VIDA

DOMINIO DE RENDIMIENTO
ENFOQUE DE DESARROLLO Y DOMINIO DE RENDIMIENTO DEL CICLO DE VIDA
El enfoque de La ejecución efectiva de este dominio de desempeño da como resultado

los siguientes resultados deseados:
desarrollo y el dominio de
rendimiento del ciclo de Enfoques de desarrollo que son consistentes con los entregables del
vida aborda las actividades proyecto.
y funciones asociadas con
Un ciclo de vida del proyecto que consta de fases que conectan la
el enfoque de desarrollo, entrega de valor comercial y para las partes interesadas desde el
la cadencia y las fases del principio hasta el final del proyecto.
ciclo de vida del proyecto. Un ciclo de vida del proyecto que consta de fases que facilitan la
cadencia de entrega y el enfoque de desarrollo necesarios para
producir los entregables del proyecto.
Figura 2-6. Enfoque de desarrollo y dominio de rendimiento del ciclo de vida
Este dominio de rendimiento implica establecer el enfoque de desarrollo, la cadencia de entrega y el ciclo de vida del proyecto necesarios
para optimizar los resultados del proyecto.

32 Guía PMBOK®
Las siguientes definiciones son relevantes para el enfoque de desarrollo y el rendimiento del ciclo de vida
Dominio:
Entregable. Cualquier producto, resultado o capacidad único y verificable para realizar un servicio que se requiere
producir para completar un proceso, fase o proyecto.
Enfoque de desarrollo. Un método utilizado para crear y evolucionar el producto, servicio o resultado durante el ciclo
de vida del proyecto, como un método predictivo, iterativo, incremental, adaptativo o híbrido.
Cadencia. Un ritmo de actividades realizadas a lo largo del proyecto.
Fase del proyecto. Una colección de actividades del proyecto relacionadas lógicamente que culmina en la finalización
de uno o más entregables.
Ciclo de vida del proyecto. La serie de fases por las que pasa un proyecto desde su inicio hasta su
finalización.
2.3.1 RELACIÓN DE DESARROLLO, CADENCIA Y CICLO DE VIDA
El tipo de entregable(s) del proyecto determina cómo se puede desarrollar. El tipo de entrega(s)
y el enfoque de desarrollo influyen en el número y la cadencia de las entregas de proyectos. El enfoque del
entregable y la cadencia de entrega deseada determinan el ciclo de vida del proyecto y sus fases.
2.3.2 CADENCIA DE ENTREGA
La cadencia de entrega se refiere al momento y la frecuencia de los entregables del proyecto. Los proyectos
pueden tener una sola entrega, varias entregas o entregas periódicas.

ÿ Entrega única. Los proyectos que tienen una sola entrega se entregan al final del proyecto. Para
Por ejemplo, es posible que un proyecto de reingeniería de procesos no tenga entregas hasta cerca del final de
el proyecto cuando se implementa el nuevo proceso.
ÿ Múltiples entregas. Algunos proyectos tienen múltiples entregas. Un proyecto puede tener múltiples
componentes que se entregan en diferentes momentos a lo largo del proyecto. Un proyecto para
desarrollar un nuevo medicamento puede tener múltiples entregas, como presentaciones preclínicas, Fase 1
resultados de la prueba, resultados de la prueba de Fase 2, resultados de la prueba de Fase 3, registro y luego lanzamiento. En esto
ejemplo, las entregas son secuenciales. Algunos proyectos tienen entregas que se desarrollan
por separado en lugar de secuencialmente, como un proyecto para actualizar la seguridad del edificio. entregas
puede incluir barreras físicas a la entrada, nuevos distintivos, nuevos teclados de códigos, etc. Cada
de estos es una entrega por separado, pero no es necesario que vengan en un orden específico. Toda la
las entregas se concluyen antes de que el proyecto se considere terminado.
ÿ Entregas periódicas. Las entregas periódicas son como entregas múltiples, pero están en un
programa de entrega fijo, como mensual o bimensual. Una nueva aplicación de software puede
tener entregas internas cada dos semanas, y luego liberar periódicamente las entregas
en el mercado
Otra opción de entrega se llama entrega continua. La entrega continua es la práctica de entregar incrementos de
funciones de inmediato a los clientes, a menudo mediante el uso de pequeños lotes de trabajo y tecnología de
automatización. La entrega continua se puede utilizar para productos digitales.
Desde la perspectiva de la gestión de productos, el énfasis está en brindar beneficios y valor a lo largo del ciclo de
vida del producto. Similar a un proyecto, hay aspectos que están orientados al desarrollo. Sin embargo, al igual que
un programa, puede haber muchos ciclos de desarrollo, así como actividades de mantenimiento. Este tipo de
emprendimiento funciona mejor con equipos de proyecto que son estables y permanecen intactos. Debido a que los
equipos de proyecto se centran en un producto, pueden aplicar el aprendizaje sobre el producto, las partes
interesadas y el mercado. Esto permite que el equipo responda a las tendencias del mercado y se mantenga
enfocado en la entrega de valor. Esta práctica está incluida en varios enfoques como DevOps, #noprojects y Continuous
Digital, por ejemplo.

34 Guía PMBOK®
2.3.3 ENFOQUES DE DESARROLLO
Un enfoque de desarrollo es el medio utilizado para crear y evolucionar el producto, servicio o resultado.
durante el ciclo de vida del proyecto. Existen diferentes enfoques de desarrollo, y diferentes industrias pueden usar
diferentes términos para referirse a los enfoques de desarrollo. Tres enfoques comúnmente utilizados son predictivo,
híbrido y adaptativo. Como se muestra en la Figura 2-7, estos enfoques a menudo se ven como un espectro, desde el
enfoque predictivo en un extremo del espectro hasta el adaptativo en el otro extremo.
Enfoques de desarrollo
Profético Híbrido Adaptado
Cada vez más iterativo e incremental
Figura 2-7. Enfoques de desarrollo
ÿ Enfoque predictivo. Un enfoque predictivo es útil cuando el proyecto y el producto

Los requisitos se pueden definir, recopilar y analizar al inicio del proyecto. Esto puede
también se denomina enfoque en cascada. Este enfoque también se puede usar cuando hay
implica una inversión significativa y un alto nivel de riesgo que puede requerir frecuentes
revisiones, mecanismos de control de cambios y replanificación entre fases de desarrollo. Él
el alcance, el cronograma, el costo, las necesidades de recursos y los riesgos pueden definirse bien en las primeras fases
del ciclo de vida del proyecto, y son relativamente estables. Este enfoque de desarrollo permite
el equipo del proyecto para reducir el nivel de incertidumbre al principio del proyecto y hacer mucho de
la planificación por adelantado. Los enfoques predictivos pueden utilizar desarrollos de prueba de concepto para
explorar opciones, pero la mayoría del trabajo del proyecto sigue los planes que se desarrollaron
cerca del inicio del proyecto. Muchas veces, los proyectos que utilizan este enfoque tienen plantillas
de proyectos anteriores similares.

Un proyecto para desarrollar un nuevo centro comunitario podría utilizar un enfoque predictivo
para la construcción de los terrenos y las instalaciones. El alcance, el cronograma, el costo y los recursos
se determinarían por adelantado y los cambios probablemente serían mínimos. El proceso de construcción
seguiría los planos y planos.
ÿ Enfoque híbrido. Un enfoque de desarrollo híbrido es una combinación de adaptativo y

enfoques predictivos. Esto significa que se utilizan algunos elementos de un enfoque predictivo y
otros de un enfoque adaptativo. Este enfoque de desarrollo es útil cuando existe incertidumbre o
riesgo en torno a los requisitos. Hybrid también es útil cuando los entregables se pueden modularizar,
o cuando hay entregables que pueden ser desarrollados por diferentes equipos de proyecto. Un
enfoque híbrido es más adaptativo que un enfoque predictivo, pero menos que un enfoque puramente
adaptativo.
Los enfoques híbridos suelen utilizar un enfoque de desarrollo iterativo o incremental. Un

enfoque iterativo es útil para aclarar los requisitos e investigar varias opciones.
Un enfoque iterativo puede producir suficiente capacidad para ser considerado aceptable antes de
la iteración final. Se utiliza un enfoque incremental para producir un producto a través de una serie de
iteraciones. Cada iteración agrega funcionalidad dentro de un marco de tiempo predeterminado (una
caja de tiempo). El entregable contiene la capacidad de ser considerado como completado solo
después de la iteración final.
Las diferencias e interacciones entre el desarrollo iterativo e incremental se muestran en la

Figura 2-8.
Un ejemplo de un enfoque híbrido podría ser el uso de un enfoque adaptativo para desarrollar
un producto que tenga una incertidumbre significativa asociada con los requisitos. Sin embargo, la
implementación del producto se puede realizar mediante un enfoque predictivo. Otro ejemplo es un
proyecto con dos entregables principales donde uno se desarrolla utilizando un enfoque adaptativo y
el otro utilizando un enfoque predictivo.

36 Guía PMBOK®
Voz
Transcripción
Iterativo
Prueba diferente
ideas para
aclarar alcance,
enfoque, y
requisitos
Cliente:
Necesito
un método
para capturar
ideas que podrían Retroalimentación y adaptación Retroalimentación y adaptación Retroalimentación y adaptación
cambio.
incrementales
progresivamente
desarrollar características
y funciones
Retroalimentación y adaptación Retroalimentación y adaptación Retroalimentación y adaptación
Figura 2-8. Desarrollo iterativo e incremental

Como parte del centro comunitario, se podría desarrollar e implementar iterativamente un proyecto para establecer servicios
para personas mayores. Por ejemplo, la primera iteración podría ser un programa Meals on Wheels. Esto podría ser seguido
por un servicio de transporte, luego salidas y eventos grupales, alivio para el cuidador, atención diurna para adultos, etc.
Cada servicio estaría completo por sí solo y podría implementarse cuando estuviera disponible. Cada servicio adicional
mejoraría y aumentaría los servicios para personas mayores para la comunidad.
Un proyecto para establecer la capacitación de los voluntarios de las patrullas de acción comunitaria podría utilizar un enfoque
incremental. La formación, compuesta por formación básica, formación en logística y formación en patrullaje, puede ser
desarrollada por diferentes personas. Se puede desarrollar al mismo tiempo en módulos, o se puede desarrollar un módulo,
recopilar comentarios y luego se pueden desarrollar módulos posteriores.
Sin embargo, el programa de capacitación de patrullas de acción comunitaria solo estará completo después de que
todos los módulos estén desarrollados, integrados e implementados.
ÿ Enfoque adaptativo. Los enfoques adaptativos son útiles cuando los requisitos están sujetos a
un alto nivel de incertidumbre y volatilidad y es probable que cambien a lo largo del proyecto. UN
se establece una visión clara al comienzo del proyecto, y los requisitos iniciales conocidos son
refinado, detallado, cambiado o reemplazado de acuerdo con los comentarios de los usuarios, el medio ambiente,
o eventos inesperados.
Los enfoques adaptativos utilizan enfoques iterativos e incrementales. Sin embargo, en el otro lado
de los métodos adaptativos, las iteraciones tienden a acortarse y es más probable que el producto
evolucionar en función de los comentarios de las partes interesadas.
Si bien la agilidad es una mentalidad amplia que es más amplia que un marco de desarrollo, ágil
Los enfoques pueden considerarse adaptativos. Algunos enfoques ágiles implican iteraciones que son
1 a 2 semanas de duración con una demostración de los logros al final de cada
iteración. El equipo del proyecto está muy comprometido con la planificación de cada iteración. El proyecto
El equipo determinará el alcance que pueden lograr con base en un backlog priorizado, estimarán el
trabajo involucrado, y trabajar en colaboración a lo largo de la iteración para desarrollar el alcance.

38 Guía PMBOK®
El centro comunitario necesitará un sitio web para que los miembros de la comunidad puedan acceder a la
información desde la computadora, el teléfono o la tableta de su hogar. Los requisitos de alto nivel, el diseño y los
diseños de página se pueden definir por adelantado. Se puede implementar un conjunto inicial de información en el sitio web.
Los comentarios de los usuarios, los nuevos servicios y las necesidades de las partes interesadas internas
proporcionarían contenido para una acumulación. Se priorizaría la información de la acumulación y el equipo web
desarrollaría e implementaría contenido nuevo. A medida que surjan nuevos requisitos y un nuevo alcance, se
desarrollarán las estimaciones para el trabajo, se realizará el trabajo y, una vez probado, se demostrará a las partes
interesadas. Si se aprueba, el trabajo se implementará en el sitio web.
2.3.4 CONSIDERACIONES PARA SELECCIONAR UN ENFOQUE DE DESARROLLO
Hay varios factores que influyen en la selección de un enfoque de desarrollo. Se pueden dividir en categorías
de producto, servicio o resultado; el proyecto; y la organización. Las siguientes subsecciones describen las variables
asociadas con cada categoría.
2.3.4.1 Producto, Servicio o Resultado
Hay muchas variables asociadas con la naturaleza del producto, servicio o resultado que influyen en el enfoque
de desarrollo. La siguiente lista describe algunas de las variables a considerar al seleccionar el enfoque de desarrollo.
ÿ Grado de innovación. Entregables donde el alcance y los requisitos están bien

entendido, que el equipo del proyecto ha trabajado antes, y que permiten la planificación
por adelantado se adaptan bien a un enfoque predictivo. Entregables que tienen un alto grado de
innovación o donde el equipo del proyecto no tiene experiencia se adaptan mejor a un
enfoque adaptativo.
ÿ Certidumbre de requisitos. Cuando los requisitos son bien conocidos y fáciles de definir, un
enfoque predictivo encaja bien. Cuando los requisitos son inciertos, volátiles o complejos y son
se espera que evolucione a lo largo del proyecto, un enfoque más adaptativo puede ser más adecuado.

ÿ Estabilidad del alcance. Si el alcance del entregable es estable y no es probable que cambie, es útil un enfoque
predictivo. Si se espera que el alcance tenga muchos cambios, puede ser útil un enfoque más cercano al lado
adaptativo del espectro.
ÿ Facilidad de cambio. En relación con la certeza de los requisitos y la estabilidad del alcance, si la naturaleza del
entregable dificulta la gestión e incorporación de cambios, lo mejor es un enfoque predictivo. Los entregables que
pueden adaptarse fácilmente al cambio pueden utilizar un enfoque que sea más adaptable.
ÿ Opciones de entrega. Como se describe en la Sección 2.3.2 sobre Cadencia de entrega, la naturaleza del
entregable y si se puede entregar en componentes influye en el enfoque de desarrollo. Los productos, servicios
o resultados que pueden desarrollarse y/o entregarse en partes están alineados con enfoques incrementales,
iterativos o adaptativos. Algunos proyectos grandes pueden planificarse utilizando un enfoque predictivo, pero
puede haber algunas piezas que pueden desarrollarse y entregarse de forma incremental.
ÿ Riesgo. Los productos que son inherentemente de alto riesgo requieren un análisis antes de elegir el
enfoque de desarrollo Algunos productos de alto riesgo pueden requerir una planificación inicial significativa y
procesos rigurosos para reducir las amenazas. Otros productos pueden reducir el riesgo construyéndolos de
forma modular y adaptando el diseño y el desarrollo en función del aprendizaje para aprovechar las oportunidades
emergentes o reducir la exposición a las amenazas.
ÿ Requisitos de seguridad. Los productos que tienen requisitos de seguridad rigurosos suelen utilizar un
enfoque predictivo, ya que existe la necesidad de una planificación inicial significativa para garantizar que
todos los requisitos de seguridad se identifiquen, planifiquen, creen, integren y prueben.
ÿ Reglamento. Los entornos que tienen una supervisión regulatoria significativa pueden necesitar usar un
enfoque predictivo debido al proceso requerido, la documentación y las necesidades de demostración.
2.3.4.2 Proyecto
Las variables del proyecto que influyen en el enfoque de desarrollo se centran en las partes interesadas,
limitaciones de horario y disponibilidad de fondos.
ÿ Partes interesadas. Los proyectos que utilizan métodos adaptativos requieren una participación significativa de las partes interesadas.
participación durante todo el proceso. Ciertas partes interesadas, como el propietario del producto,
desempeñan un papel importante en el establecimiento y la priorización del trabajo.

40 Guía PMBOK®
ÿ Restricciones de horario. Si existe la necesidad de entregar algo temprano, incluso si no es un producto

terminado, es beneficioso un enfoque iterativo o adaptativo.
ÿ Disponibilidad de fondos. Los proyectos que funcionan en un entorno de incertidumbre financiera pueden
beneficiarse de un enfoque adaptativo o iterativo. Se puede lanzar un producto mínimo viable con menos inversión
que un producto elaborado. Esto permite realizar pruebas de mercado o capturar el mercado con una inversión
mínima. Se pueden realizar inversiones adicionales en función de la respuesta del mercado al producto o servicio.
2.3.4.3 Organización
Variables organizacionales tales como la estructura, cultura, capacidad, tamaño del equipo del proyecto y
la ubicación influye en el enfoque de desarrollo.
ÿ Estructura organizativa. Una estructura organizativa que tiene muchos niveles, un rígido
la estructura de informes y la burocracia sustancial utilizan con frecuencia un enfoque predictivo.
Los proyectos que usan métodos adaptativos tienden a tener una estructura plana y pueden operar con equipos de
proyecto autoorganizados.
ÿ Cultura. Un enfoque predictivo encaja mejor en una organización con una cultura de gestión
y dirección, donde se planifica el trabajo y se mide el progreso con respecto a las líneas de base.
Los enfoques adaptativos encajan mejor dentro de una organización que enfatiza la autogestión del equipo del
proyecto.
ÿ Capacidad organizativa. La transición de enfoques de desarrollo predictivo a enfoques adaptativos y luego al uso
de métodos ágiles es más que solo afirmar que la organización ahora será ágil. Implica cambiar la mentalidad a
partir del nivel ejecutivo en toda la organización. Las políticas organizacionales, las formas de trabajar, la estructura
de informes y la actitud deben alinearse para emplear métodos adaptativos con éxito.
ÿ Tamaño y ubicación del equipo del proyecto. Los enfoques adaptativos, especialmente los métodos ágiles, a menudo
trabaje mejor con equipos de proyecto de 7 ± 2. Los enfoques adaptativos también favorecen a los equipos de
proyecto que se encuentran en el mismo espacio físico. Los equipos de proyectos grandes y los equipos de proyectos
que son en su mayoría virtuales pueden hacerlo mejor si utilizan un enfoque más cercano al lado predictivo del espectro.
Sin embargo, existen enfoques que buscan ampliar los enfoques adaptativos para trabajar con equipos de proyecto
grandes y dispersos.

2.3.5 DEFINICIONES DE CICLO DE VIDA Y FASE

El tipo y el número de fases del proyecto en el ciclo de vida de un proyecto dependen de muchas variables, entre las
que destacan la cadencia de entrega y el enfoque de desarrollo, como se describió anteriormente.
Ejemplos de fases en un ciclo de vida incluyen:
ÿ Viabilidad. Esta fase determina si el caso de negocio es válido y si la organización tiene

la capacidad de entregar el resultado deseado.
ÿ Diseño. La planificación y el análisis conducen al diseño del entregable del proyecto que será
desarrollado.
ÿ Construir. La construcción del entregable con actividades integradas de aseguramiento de la calidad es

realizado.
ÿ Prueba. La revisión de calidad final y la inspección de los entregables se llevan a cabo antes de la transición,
go-live, o aceptación por parte del cliente.
ÿ Implementar. Los entregables del proyecto se ponen en uso y se requieren actividades de transición para
se completan el mantenimiento, la realización de beneficios y la gestión del cambio organizacional.
ÿ Cerrar. El proyecto está cerrado, el conocimiento del proyecto y los artefactos están archivados, el equipo del proyecto
los miembros son liberados y los contratos se cierran.
Las fases del proyecto a menudo tienen una revisión de puerta de fase (también conocida como puerta de etapa) para
verificar que se hayan logrado los resultados deseados o los criterios de salida para la fase antes de pasar a la siguiente fase.
Los criterios de salida pueden estar vinculados a criterios de aceptación de entregables, obligaciones contractuales, cumplimiento
de objetivos de desempeño específicos u otras medidas tangibles.

42 Guía PMBOK®
La figura 2-9 muestra un ciclo de vida en el que termina una fase antes de que comience la siguiente.
Este tipo de ciclo de vida encajaría bien con un enfoque de desarrollo predictivo, ya que cada fase solo se
realiza una vez y cada fase se enfoca en un tipo particular de trabajo. Sin embargo, hay situaciones, como
la adición de alcance, un cambio en los requisitos o un cambio en el mercado que hacen que se repitan fases.
Ejemplo de ciclo de vida predictivo
Factibilidad
Diseño
Construir
Prueba
Desplegar
Cerrar
Figura 2-9. Ejemplo de ciclo de vida predictivo

La Figura 2-10 muestra un ciclo de vida con un enfoque de desarrollo incremental. Hay tres
iteraciones de plan, diseño y construcción que se muestran en este ejemplo. Cada compilación posterior agregaría funcionalidad a
la compilación inicial.
Ejemplo de ciclo de vida con un enfoque de desarrollo incremental
Concepto
Plan Plan Plan
Diseño Diseño Diseño
Construir Construir Construir
Cerrar
Figura 2-10. Ciclo de vida con un enfoque de desarrollo incremental

44 Guía PMBOK®
La Figura 2-11 muestra un ciclo de vida utilizando un enfoque de desarrollo adaptativo. Al final de cada iteración
(a veces conocida como sprint), el cliente revisa un entregable funcional. En la revisión, las partes interesadas clave brindan
comentarios y el equipo del proyecto actualiza la acumulación de características y funciones del proyecto para priorizar para la
próxima iteración.
Ciclo de vida utilizando el enfoque de desarrollo adaptativo
Definir Proyecto
y
Visión del producto
Iteración 1 Iteración 2 Iteración 3
Comentario Comentario
Reserva Reserva
Priorización Priorización
Figura 2-11. Ciclo de vida con enfoque de desarrollo adaptativo
Este enfoque se puede modificar para su uso en situaciones de entrega continua, como se describe en
Apartado 2.3.2 sobre Cadencia de Entrega.
Varias metodologías adaptativas, incluidas las ágiles, utilizan la programación basada en el flujo, que no utiliza un ciclo de
vida o fases. Uno de los objetivos es optimizar el flujo de entregas en función de la capacidad de los recursos, los materiales
y otros insumos. Otro objetivo es minimizar el desperdicio de tiempo y recursos y optimizar la eficiencia de los procesos y
el rendimiento de los entregables. Los proyectos que utilizan estas prácticas y métodos generalmente los adoptan del
sistema de programación Kanban utilizado en los enfoques de programación lean y justo a tiempo.

2.3.6 ALINEACIÓN DE LA CADENCIA DE ENTREGA, EL ENFOQUE DE DESARROLLO Y EL CICLO DE

VIDA
Se revisarán los ejemplos de centros comunitarios descritos en la Sección 2.3.3 para demostrar cómo encajan la cadencia de
entrega, el enfoque de desarrollo y el ciclo de vida. En este ejemplo, hay cuatro productos y servicios: el edificio, la capacitación de la patrulla
de acción comunitaria (CAP), los servicios para personas mayores y el sitio web. La Tabla 2-4 describe la cadencia de entrega y el enfoque de
desarrollo.
Tabla 2-4. Cadencia de entrega y enfoque de desarrollo
Entregable Cadencia de entrega Enfoque de desarrollo
Edificio entrega única Profético
Servicios para personas mayores Múltiples entregas Iterativo
Sitio web Entregas periódicas Adaptado
Capacitación de patrullas de acción comunitaria Múltiples entregas incrementales
Con base en esta información, un ciclo de vida potencial podría ser:
ÿ Puesta en marcha. Los criterios de entrada para esta fase son que el caso de negocio haya sido aprobado y
el acta de constitución del proyecto ha sido autorizada. En esta fase, se desarrolla la hoja de ruta de alto nivel,
se establecen los requisitos iniciales de financiación, se establecen los requisitos del equipo del proyecto y de los recursos.
se define, se crea un cronograma de hitos y se define la planificación de una estrategia de adquisiciones.
Estos entregables deben estar completos antes de salir de la fase de puesta en marcha. Los criterios de salida serán
revisado en una revisión de puerta de fase de originación.
ÿ Planificar. En esta fase, la información de alto nivel para el edificio se descompone en información detallada.
planes Se completa un documento de diseño detallado para la capacitación CAP. un analisis de la
La oferta de servicios para personas mayores se completa junto con un análisis de brechas. La estructura alámbrica inicial para
se crea el sitio web. Estos entregables deben estar completos antes de salir de la planificación.
fase. Los criterios de salida se revisarán en una revisión inicial de la fase de planificación.

46 Guía PMBOK®
ÿ Desarrollo. Esta fase se superpondrá con las fases de prueba e implementación ya que la
los entregables tienen diferentes cadencias de entrega y diferentes enfoques. El sitio web tendrá
entregas anticipadas para informar al público sobre el progreso del centro comunitario. Algunos servicios
para personas mayores y la capacitación CAP pueden comenzar antes de la apertura del centro
comunitario. Cada entregable puede tener una revisión por separado antes de entrar en la fase de prueba.
ÿ Prueba. Esta fase se superpondrá con las fases de desarrollo e implementación. El tipo de prueba
dependerá del entregable. Esta fase incluye inspecciones del edificio, una entrega beta de los cursos
CAP, pruebas a pequeña escala para los servicios para personas mayores y operar en un entorno de
prueba para cada versión del sitio web. Cada entregable pasará por las pruebas correspondientes
antes de pasar a la fase de implementación.
ÿ Implementar. Esta fase se superpondrá con las fases de desarrollo y prueba. La primera implementación
del sitio web puede ser algo temprana en el proyecto. Las actividades en esta fase se repetirán a medida
que haya más entregables disponibles. El despliegue final del proyecto será la apertura del centro
comunitario. Las actualizaciones continuas del sitio web y los servicios para personas mayores serán parte
de las operaciones una vez que el centro comunitario esté abierto.
ÿ Cerrar. Esta fase se lleva a cabo periódicamente a medida que se completan los entregables. Cuando se
haya implementado el sitio web inicial, se liberará al personal del proyecto (incluidos los contratistas) y
se completarán las retrospectivas o las lecciones aprendidas para cada entregable. Cuando todo el
proyecto esté terminado, se llevará a cabo la información de las diversas revisiones de puerta de fase y
una evaluación general del desempeño del proyecto en comparación con las líneas de base. Antes del
cierre final, se revisarán el acta de constitución del proyecto y el caso comercial para determinar si los
entregables lograron los beneficios y el valor previstos.

La Figura 2-12 muestra un posible ciclo de vida para el proyecto del centro comunitario. La puesta en marcha y
Las fases de planificación son secuenciales. Las fases de desarrollo, prueba e implementación se superponen
porque los diferentes entregables se desarrollarán, probarán e implementarán en diferentes momentos, y algunos
entregables tendrán múltiples entregas. La fase de desarrollo se muestra con más detalle para demostrar diferentes
tiempos y cadencias de entrega. La cadencia de la fase de prueba seguiría la cadencia de la fase de desarrollo. Las
entregas se muestran en la fase de despliegue.
Origen
Revisar Ciclo de vida del centro comunitario
Planificación
Revisar
Puesta en marcha
Plan
Desarrollo
Comunidad
Prueba centro abierto
Desplegar
Sitio web Sénior Acción Comunitaria

Lanzamiento 1 ofrendas Lanzamiento de entrenamiento de patrulla
Cerrar
Desarrollo de sitios web y entregas
Iteraciones de servicio senior
Servicio Mayor Servicio Mayor Servicio Mayor Servicio Mayor

Lanzamiento 1 Lanzamiento 2 Lanzamiento 3 Lanzamiento 4
LLAVE:
Hito
Incrementos en el entrenamiento de la Patrulla de Acción Comunitaria entregas
Módulo 1: Módulo 2: Módulo 3:

Integración
Entrenamiento básico Capacitación en Logística Entrenamiento de Patrulla
Construcción del Centro Comunitario
Figura 2-12. Ciclo de vida del centro comunitario
48 Guía PMBOK®
¿Lo que hay en un nombre? No todos los profesionales de proyectos diferencian entre el enfoque de desarrollo y el
ciclo de vida. Algunos profesionales dirán que un proyecto sigue un ciclo de vida ágil cuando en realidad están hablando del
enfoque de desarrollo. Algunos profesionales se refieren a los enfoques predictivos como cascada. Los enfoques de desarrollo
adaptativo también pueden conocerse como enfoques evolutivos.
Debido a que la gestión de proyectos está evolucionando, el lenguaje utilizado continúa evolucionando. La mejor manera de
entender a qué se refiere una persona es determinar cómo está desarrollando los entregables y preguntarle los nombres de
las fases del ciclo de vida. Esto puede ayudar a enmarcar el proyecto y comprender cómo las personas usan los términos.

El enfoque de desarrollo y el dominio de desempeño del ciclo de vida interactúan con el
Dominios de las partes interesadas, la planificación, la incertidumbre, la entrega, el trabajo del proyecto y el rendimiento del equipo.
El ciclo de vida seleccionado influye en la forma en que se lleva a cabo la planificación. Los ciclos de vida predictivos llevan a cabo la
mayor parte de la planificación por adelantado y luego continúan replanificándose mediante la planificación de ondas continuas y la
elaboración progresiva. Los planes también se actualizan a medida que se materializan las amenazas y las oportunidades.
El enfoque de desarrollo y la cadencia de entrega es una forma de reducir la incertidumbre en los proyectos.
Un producto que tiene mucho riesgo asociado con el cumplimiento de los requisitos reglamentarios puede elegir un enfoque
predictivo para incorporar pruebas adicionales, documentación y procesos y procedimientos sólidos.
Un entregable que tiene mucho riesgo asociado con la aceptación de las partes interesadas puede elegir un enfoque iterativo y
lanzar un producto viable mínimo al mercado para obtener retroalimentación antes de desarrollar características y funciones
adicionales.

El enfoque de desarrollo y el dominio de rendimiento del ciclo de vida tienen una superposición significativa
con el dominio de rendimiento de entrega al considerar la cadencia de entrega y el enfoque de desarrollo.
La cadencia de entrega es uno de los principales impulsores de la entrega de valor en consonancia con el caso de
negocio y los planes de realización de beneficios. La obtención de los requisitos del producto y el cumplimiento de los
requisitos de calidad, tal como se describe en el Dominio del desempeño de la entrega, tienen una influencia
significativa en el enfoque de desarrollo.
El Dominio de rendimiento del equipo y el Enfoque de desarrollo y el Dominio de rendimiento del ciclo de vida
interactúan cuando se trata de las capacidades del equipo del proyecto y las habilidades de liderazgo del equipo del
proyecto. La forma de trabajar del equipo del proyecto y el estilo del director del proyecto varían significativamente según
el enfoque de desarrollo. Un enfoque predictivo generalmente implica más énfasis en la planificación, la medición y el
control por adelantado. En el otro extremo del espectro, un enfoque adaptativo, especialmente cuando se utilizan métodos
ágiles, requiere más un estilo de liderazgo de servicio y puede tener equipos de proyecto autogestionados.
2.3.8 MEDICIÓN DE RESULTADOS
La tabla 2-5 identifica los resultados a la izquierda y las formas de verificarlos a la derecha.
Tabla 2-5. Comprobación de resultados: enfoque de desarrollo y dominio de rendimiento del ciclo de vida
Salir Cheque
Enfoques de desarrollo que son consistentes con El enfoque de desarrollo de entregables (predictivo, híbrido o adaptativo) refleja las variables del producto y
los entregables del proyecto es apropiado dadas las variables organizacionales y del proyecto.
Un ciclo de vida del proyecto que consta de El trabajo del proyecto desde el lanzamiento hasta el cierre está representado en las fases del proyecto.
fases que conectan la entrega de valor comercial y Las fases incluyen criterios de salida apropiados.
para las partes interesadas desde el principio hasta
el final del proyecto.
Fases del ciclo de vida del proyecto que La cadencia de desarrollo, prueba e implementación se representa en las fases del ciclo de vida. Los proyectos
facilitan la cadencia de entrega y el enfoque de con múltiples entregables que tienen diferentes cadencias de entrega y métodos de desarrollo se representan
desarrollo requerido para producir los entregables mediante fases superpuestas o repeticiones de fase, según sea necesario.
del proyecto

50 Guía PMBOK®
2.4 DOMINIO DE DESEMPEÑO DE LA PLANIFICACIÓN
La planificación organiza, elabora y coordina el trabajo del proyecto a lo largo del proyecto.
DOMINIO DE DESEMPEÑO DE LA PLANIFICACIÓN
El desempeño de la planificación La ejecución efectiva de este dominio de desempeño da como resultado los
El dominio aborda las siguientes resultados deseados:
actividades y funciones
El proyecto avanza de manera organizada, coordinada y deliberada.
asociadas con la inicial,
organización y coordinación Hay un enfoque holístico para entregar el proyecto.
continuas y en evolución resultados.
necesarias para entregar los La información en evolución se elabora para producir los
entregables del proyecto y entregables y los resultados para los cuales se emprendió el
proyecto.
resultados. El tiempo dedicado a la planificación es apropiado para la situación.
La información de planificación es suficiente para gestionar las expectativas de las

partes interesadas.
Existe un proceso de adecuación de planes a lo largo

el proyecto basado en necesidades o condiciones emergentes y
cambiantes.
Figura 2-13. Dominio de rendimiento de la planificación

Las siguientes definiciones son relevantes para el dominio de desempeño de la planificación:
Estimar. Una evaluación cuantitativa de la cantidad o el resultado probable de una variable, como los costos, los
recursos, el esfuerzo o la duración del proyecto.
Exactitud. Dentro del sistema de gestión de la calidad, la precisión es una evaluación de la corrección.
Precisión. Dentro del sistema de gestión de la calidad, la precisión es una evaluación de la exactitud.
chocando Un método utilizado para acortar la duración del cronograma al menor costo incremental mediante la adición
de recursos.
Seguimiento rápido. Un método de compresión del cronograma en el que las actividades o fases que normalmente se
realizan en secuencia se realizan en paralelo durante al menos una parte de su duración.
Presupuesto. La estimación aprobada para el proyecto o cualquier componente de la estructura de desglose del
trabajo (EDT) o cualquier actividad del cronograma.
2.4.1 DESCRIPCIÓN GENERAL DE LA PLANIFICACIÓN
El propósito de la planificación es desarrollar proactivamente un enfoque para crear los entregables del
proyecto. Los entregables del proyecto impulsan los resultados para los cuales se emprendió el proyecto.
La planificación de alto nivel puede comenzar antes de la autorización del proyecto. El equipo del proyecto elabora
progresivamente los documentos iniciales del proyecto, como una declaración de visión, un acta de constitución del
proyecto, un caso comercial o documentos similares para identificar o definir un camino coordinado para lograr los resultados deseados.

52 Guía PMBOK®
Cada vez es más común que la planificación inicial considere los impactos sociales y ambientales además de los
impactos financieros (a veces denominado triple resultado). Esto puede tomar la forma de una evaluación del ciclo de
vida del producto que evalúa los impactos ambientales potenciales de un producto, proceso o sistema. La evaluación del
ciclo de vida del producto informa el diseño de productos y procesos. Considera los impactos de los materiales y procesos
con respecto a la sostenibilidad, la toxicidad y el medio ambiente.
La cantidad de tiempo dedicado a la planificación, tanto al principio como a lo largo del proyecto, debe estar
determinada por las circunstancias. Es ineficiente dedicar más tiempo a la planificación del necesario.
Por lo tanto, la información obtenida de la planificación debe ser suficiente para avanzar de manera adecuada, pero
no más detallada de lo necesario. Los equipos de proyecto usan artefactos de planificación para confirmar las expectativas
de los interesados y proporcionarles la información que necesitan para tomar decisiones, tomar medidas y mantener la
alineación entre el proyecto y los interesados.
2.4.2 VARIABLES DE PLANIFICACIÓN
Debido a que cada proyecto es único, la cantidad, el tiempo y la frecuencia de la planificación varían. Variables
que influyen en cómo se lleva a cabo la planificación del proyecto incluyen, pero no se limitan a:
ÿ Enfoque de desarrollo. El enfoque de desarrollo puede influir en cómo, cuánto y

cuando se lleva a cabo la planificación. Ejemplos incluyen:
ÿ Una fase específica para planificar u organizar al principio del ciclo de vida. En estas situaciones, mucho
de la planificación se realiza por adelantado. Los planes iniciales se elaboran progresivamente con
más detalles a lo largo del proyecto, pero hay pocos cambios en el alcance original.
ÿ Un enfoque con una planificación de alto nivel por adelantado, seguida de una fase de diseño en la que
Se utiliza la creación de prototipos. Después de que el equipo del proyecto y las partes interesadas estén de acuerdo con el diseño,
el equipo del proyecto completa una planificación más detallada.
ÿ Enfoques adaptativos en los que el equipo del proyecto realiza iteraciones. Algo de planificación
ocurre por adelantado para establecer planes de liberación y la planificación adicional ocurre en el
comienzo de cada iteración.

ÿ Entregables del proyecto. A menudo, los entregables del proyecto requieren una planificación específica.
Los proyectos de construcción requieren una planificación inicial significativa para tener en cuenta el diseño, las aprobaciones,
compra de materiales, logística y entrega. Desarrollo de productos o alta tecnología
los proyectos pueden usar una planificación continua y adaptativa para permitir la evolución y los cambios
basado en la retroalimentación de las partes interesadas y los avances tecnológicos.
ÿ Requisitos organizativos. Gobernanza organizacional, políticas, procedimientos, procesos,

y la cultura puede requerir que los gerentes de proyecto produzcan artefactos de planificación específicos.
ÿ Condiciones de mercado. Los proyectos de desarrollo de productos pueden tener lugar en un entorno altamente competitivo.
medioambiente. En estas situaciones, los equipos de proyecto pueden realizar una cantidad mínima de
planificación inicial ya que el énfasis está en la velocidad de comercialización. El costo de una demora tan extensa
implica la planificación excede el riesgo de reelaboración potencial.
ÿ Restricciones legales o reglamentarias. Las agencias reguladoras o los estatutos pueden requerir
documentos de planificación antes de otorgar una autorización para proceder o para obtener la aprobación para
lanzar el entregable del proyecto al mercado.
2.4.2.1 Entrega
La planificación comienza con la comprensión del caso comercial, los requisitos de las partes interesadas y el alcance del
proyecto y del producto. El alcance del producto son las características y funciones que caracterizan un producto, servicio o resultado. El
alcance del proyecto es el trabajo realizado para entregar un producto, servicio o resultado con las características y funciones especificadas.
Los enfoques de planificación predictiva comienzan con los entregables del proyecto de alto nivel por adelantado y los
descomponen en más detalles. Este enfoque puede emplear una declaración de alcance y/o una estructura de desglose del trabajo
(WBS) para descomponer el alcance en niveles más bajos de detalle.
Los proyectos que usan enfoques iterativos o incrementales pueden tener temas o epopeyas de alto nivel
que se descomponen en funciones, que luego se descomponen en historias de usuario y otros elementos pendientes. Se puede
priorizar el trabajo que es único, significativo, arriesgado o novedoso para reducir la incertidumbre asociada con el alcance del proyecto al
inicio del proyecto antes de que se haya realizado una inversión significativa. Los equipos de proyecto planifican el trabajo de rutina basado
en el concepto del último momento responsable. Este enfoque difiere la decisión de permitir que el equipo del proyecto considere múltiples
opciones hasta que el costo de una mayor demora exceda el beneficio. Reduce el desperdicio al no perder tiempo en desarrollar planes de
trabajo que pueden cambiar o no ser necesarios.

54 Guía PMBOK®
2.4.2.2 Estimación
La planificación implica el desarrollo de estimaciones del esfuerzo de trabajo, la duración, los costos, las personas
y los recursos físicos. Las estimaciones son una evaluación cuantitativa de la cantidad o el resultado probable de una
variable, como los costos, los recursos, el esfuerzo o la duración del proyecto. A medida que el proyecto evoluciona, las
estimaciones pueden cambiar según la información y las circunstancias actuales. La fase del proyecto en el ciclo de vida
impacta cuatro aspectos asociados con la estimación:
ÿ Alcance. Las estimaciones tienden a tener un rango amplio al comienzo del proyecto cuando no hay mucha
información sobre el alcance del proyecto y del producto, las partes interesadas, los requisitos, los riesgos y otra
información. La figura 2-14 muestra un rango de -25 a +75 % al comienzo de la exploración de una oportunidad
de proyecto. Los proyectos que están bien avanzados en su ciclo de vida pueden tener un rango estimado de -5
a +10%.
ÿ Precisión. La precisión se refiere a la exactitud de una estimación. La precisión está vinculada al rango en el
sentido de que cuanto menor sea la precisión, mayor será el rango potencial de valores. Una estimación al
comienzo del proyecto tendrá menos precisión que una que se desarrolle a la mitad del proyecto.
ÿ Precisión. La precisión es diferente de la exactitud (vea la Figura 2-15). La precisión se refiere al grado de
exactitud asociado con la estimación. Por ejemplo, una estimación de 2 días es más precisa que "en algún
momento de esta semana". La precisión de las estimaciones debe ser compatible con la precisión deseada.
ÿ Confianza. La confianza aumenta con la experiencia. La experiencia de trabajar en un proyecto anterior similar
puede ayudar con el nivel de confianza requerido. Para los componentes tecnológicos nuevos y en evolución,
se espera que la confianza en las estimaciones sea baja.

Guía Pmbok®: Y El Estándar

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guía Pmbok®: Y El Estándar

Uploaded by

Copyright:

Available Formats

Machine Translated by Google

Una guía para el proyecto

PMI Séptima Edición Julio 2021

PMI Séptima Edición Julio 2021

Datos de catalogación en publicación de la Biblioteca del Congreso

Nombres: Project Management Institute, editorial.

Materias: LCSH: Gestión de proyectos – Normas

Registro de LC disponible en https://lccn.loc.gov/2021011107

Registro de libro electrónico de LC disponible en https://lccn.loc.gov/2021011108

PMI Séptima Edición Julio 2021

Correo electrónico: atenció[email protected]

©2021 Project Management Institute, Inc. Todos los derechos reservados.

Chicago, IL 60610 EE. UU.

Correo electrónico: [email protected] (solo para pedidos)

PMI Séptima Edición Julio 2021

PMI Séptima Edición Julio 2021

Al publicar y poner a disposición este documento, PMI no se compromete a brindar

PMI Séptima Edición Julio 2021

PMI Séptima Edición Julio 2021

DISEÑO CENTRADO EN EL CLIENTE Y EL USUARIO FINAL

ÿ Encuestas en línea a muestras representativas de partes interesadas de PMI;

ÿ Talleres interactivos con profesionales en varios eventos de PMI en todo el mundo.

PMI Séptima Edición Julio 2021

Los comentarios y aportes enfatizaron colectivamente cuatro puntos clave:

ÿ Mantener y mejorar la credibilidad y relevancia de la Guía PMBOK® .

ÿ Detectar las necesidades de información y contenido de las partes interesadas y proporcionar

MANTENER LA PERTINENCIA DE LA GUÍA PMBOK ®

PMI Séptima Edición Julio 2021

Evolución de los cambios clave en la Guía del PMBOK®

PMI Séptima Edición Julio 2021

ÿ Eso podría documentarse;

ÿ A través del cual se podría evaluar el desempeño frente a los procesos; y

PMI Séptima Edición Julio 2021

PMI Séptima Edición Julio 2021

Las ediciones anteriores de la Guía PMBOK® enfatizaron la importancia de adaptar el proyecto

PMI Séptima Edición Julio 2021

Guía del PMBOK® – Sexta edición Guía PMBOK® – Séptima edición

Seguimiento y Control • Cierre vida • Adaptación

Apéndices, glosario e índice Apéndices, glosario e índice

Plataforma de contenido digital PMIstandards+TM

PMI Séptima Edición Julio 2021

PMI Séptima Edición Julio 2021

1. INTRODUCCIÓN ................................................ ..................................3 1.1 Propósito

2 UN SISTEMA PARA LA ENTREGA DE VALOR ........................................... ...........7

PMI Séptima Edición Julio 2021

3 PRINCIPIOS DE LA GESTIÓN DE PROYECTOS ........................................... 21

3.1 Sea un administrador diligente, respetuoso y comprensivo ..................24 3.2 Cree un

ÍNDICE .................................................. .................................................... 61

PMI Séptima Edición Julio 2021

UNA GUÍA PARA LA GESTIÓN DE PROYECTOS

1. INTRODUCCIÓN ............................................... ....................................3

2.3.8 Medición de resultados ............................................... .......50

PMI Séptima Edición Julio 2021

2.4 Dominio del rendimiento de la planificación ............................................... ...51

PMI Séptima Edición Julio 2021

2.7.4 Errores de medición .................................................. ......111 2.7.5 Solución de

problemas de rendimiento ...........................113 2.7.6 Creciendo y

2.7.8 Comprobación de resultados ............................................. ............115 2.8

2.8.7 Comprobación de resultados ............................................. ............129

3. SASTRERÍA ............................................................. ..........................................131

3.2 ¿Por qué personalizar? .................................................... ..........................133 3.3 Qué

3.3.1 Ciclo de vida y selección del enfoque de desarrollo ........134 3.3.2

3.3.3 Compromiso.................................................... ....................136 3.3.4