Este documento resume los principales cambios introducidos en la última versión de la Guía de Administración de Proyectos del PMI. Explica que ahora incluye más referencias a otros documentos del PMI como el Análisis de Negocios y el Cambio Organizacional. También describe los nuevos elementos clave como los ciclos de vida de proyectos y desarrollo, las fases del proyecto y los "phase gates". Finalmente, resume que la guía ahora es más descriptiva que prescriptiva para permitir la personalización de la administración de proyectos

1. 22 de Septiembre de 2017
www.bawarp.com
Entendiendo la Guía de Administración de Proyectos del PMI® Sergio Luis Conte
P a g e | 1
INTRODUCCION.
1.1. Overview y Propósito de la Guía.
Según el PMI® enuncia en la Guía los proyectos se han utilizado desde hace siglos en
emprendimientos tales como construir una pirámide, organizar una olimpíada, crear una vacuna,
poner un satélite en órbita, y otros y los resultados de estos proyectos se han logrado gracias a la
aplicación de prácticas, principios, procesos, herramientas y técnicas pertenecientes a la
administración de proyectos. Los administradores de esos proyectos utilizaron un conjunto de
habilidades y conocimiento para satisfacer a sus clientes y otras personas involucradas y afectadas
por cada uno de los proyectos.
Por esta razón hacia mediados del siglo 20 se comenzó a trabajar en obtener consenso sobre el
cuerpo de conocimiento de la administración de proyectos y fue el PMI® quién compiló todo ese
cuerpo de conocimiento en el llamado PMBOK®. El PMI® reconoce que todo el conocimiento no
puede compilarse en un solo libro ya que incluye tanto materiales publicados como no publicados.
Por esta razón decidió generar un subconjunto del PMBOK® reconocido en forma general como
buena práctica y compilarlo y publicarlo en la PMBOK Guide®.
Es crítico prestar atención al significado que el PMI® asigna a dos términos clave:
 Reconocido en forma general significa que el conocimiento y prácticas descriptas son
aplicables a la mayoría de los proyectos la mayoría del tiempo y existe consenso acerca de
su valor y utilidad.
 Buena práctica significa que hay acuerdo general que la aplicación del conocimiento,
habilidades, herramientas y técnicas a los procesos de la administración de proyectos puede
mejorar la chance de éxito en una gran cantidad de proyectos respecto a entregar los
resultados de negocio y el valor de negocio esperado.
Otro punto importante a tener en cuenta es que para el PMI® el administrador de proyecto trabaja
con el equipo de proyecto y otros interesados para determinar y usar las buenas prácticas
generalmente reconocidas que son las apropiadas para cada proyecto. Esto se conoce como
“Tailoring”.
Para el mismo PMI®, la Guía del PMBOK® no es una metodología. Es el fundamento sobre el cuál las
organizaciones pueden construir metodologías, políticas, procedimientos, reglas, herramientas y
técnicas así como también las fases del ciclo de vida necesarias para la práctica de la administración
de proyectos. La Guía está construida sobre el Standard for Project Management® que es incluido
en la Parte II del documento que contiene la Guía. La Guía no es prescriptiva sino que al contrario
es descriptiva dada la necesidad de hacer “Tailoring” de la administración de proyectos para cada
proyecto en particular.
1.2. Elementos Fundamentales o Fundacionales.
Se refuerzan las definiciones de proyecto como emprendimiento temporal para crear un producto,
servicio o resultado único enfatizando:

2. 22 de Septiembre de 2017
www.bawarp.com
Entendiendo la Guía de Administración de Proyectos del PMI® Sergio Luis Conte
P a g e | 2
 Producto, servicio, o resultado único. Los proyectos se realizan para cumplir con objetivos
produciendo entregables. Los entregables pueden ser tangibles o intangibles, siempre
verificables y requeridos para completar un proceso, fase o proyecto. Las condiciones
determinan que sea único.
 Emprendimiento temporal. Todo proyecto tendrá un comienzo y un final. Se refuerza que
si bien los proyectos son temporales los entregables pueden existir más allá del final del
proyecto.
 Los proyectos dirigen el cambio. Esto es nuevo. El PMI® reconoce que un proyecto tiene
sentido para mover la organización de un estado actual a un estado futuro para obtener un
objetivo específico. En este punto están relacionando con la Managing Change in
Organizations: A Practice Guide®. La Guía agrega una figura interesante para ver esto (figura
1-1).
 Los proyectos habilitan la creación de valor. También una novedad. El PMI® define valor de
negocio como el beneficio neto cuantificable derivado de un emprendimiento de negocio.
El beneficio puede ser tangible, intangible o ambos. En este punto esta relacionando con la
Business Analysis for Practitioners: A Practice Guide®.
 El Contexto de Inicio de un Proyecto. El PMI® reconoce que los líderes de las organizaciones
inician proyectos en respuesta a factores internos pero sobre todo externos a la
organización. De esta forma se incluye la Teoría de Sistemasi
aplicada a las organizaciones
que es base para relacionar, en este caso en forma implícita, con la futura Guía del Análisis
de Negocio que será publicada próximamente por el PMI.
1.2.2. La importancia de la Administración de Proyectos.
En este punto se establece la definición de Administración de Proyectos como la aplicación de
conocimiento, habilidades, herramientas y técnicas a las actividades del proyecto para alcanzar los
requerimientos del proyecto. Esto se logra, según el PMI®, gracias a la aplicación e integración
apropiada de los procesos de administración de proyectos identificados para un proyecto en
particular.
Se remarca que la administración de proyectos debería ser considerada una competencia
estratégica dentro de las organizaciones ya que permite a estas “atar” los resultados de los
proyectos a las metas del negocio, competir en forma efectiva en su mercado, sostener la
organización y responder a los impactos del cambio en el ambiente del negocio ajustando los planes
de administración de proyecto (otra vez una relación implícita con Análisis de Negocio a través de
la Teoría de Sistemas aplicada a las organizaciones).
1.2.3. Relación entre Proyectos, Programas, Portafolios y Operaciones.
Los cambios más importantes en esta sesión son mostrar claramente (incluyendo gráficos muy
simples) la relación entre estrategia, portafolios, programas y proyectos y operaciones en cuanto a
que desde las operaciones se puede evaluar la realización del valor de negocio definido para
retroalimentar a la estrategia mientras que en los portafolios y programas/proyectos las decisiones
sobre entregar valor que se toman en los primeros que se liberan gracias a los segundos implican
un análisis de impacto continuo. El trabajo de evaluar la realización de valor desde las operaciones
es una de las actividades de Análisis de Negocio. Ver la figura 1-3 en la Guía.

3. 22 de Septiembre de 2017
www.bawarp.com
Entendiendo la Guía de Administración de Proyectos del PMI® Sergio Luis Conte
P a g e | 3
Otra incorporación es lo que en la Guía se denominan PMBOK Guide Key Components®, a saber:
1.2.4.1. Ciclo de Vida del Proyecto y del Desarrollo.
Esta puede considerarse una salida “elegante” para incorporar las nuevas tendencias tales como
Agile y Lean. Para esto formula al Ciclo de Vida de Desarrollo como subconjunto del Ciclo de Vida
del Proyecto.
El PMI® define el Ciclo de Vida del Proyecto como una seria de fases que el proyecto pasa desde su
inicio hasta su finalización. El Ciclo de Vida del Proyecto provee el marco básico para administrar el
proyecto. Los Ciclos de Vida del Proyecto pueden ser predictivos o adaptativos. Dentro del Ciclo de
Vida del Proyecto se encuentran una o más fases que están asociadas al desarrollo del producto,
servicio o resultado. A estas se las denomina Ciclo de Vida del Desarrollo. Los Ciclos de Vida del
Desarrollo pueden ser predictivos, iterativos, incrementales, adaptativos o híbridos. Según el PMI®
las diferencias entre estos Ciclo de Vida del Desarrollo son:
 En los predictivos, también llamados Cascada (Waterfall) según el PMIii
, el alcance, tiempo
y costo se determinan en etapas tempranas del ciclo de vida del proyecto y todo cambio
se administra cuidadosamente.
 En los iterativos el alcance es determinado en etapas tempranas del ciclo de vida del
proyecto pero el tiempo y costo se modifican al tiempo que el entendimiento del producto
se incrementa. Cada incremento libera nueva funcionalidad del producto.
 En los incrementales el entregable se produce a través de una serie de iteraciones que
agregan funcionalidad dentro de un tiempo predeterminado.
 Los adaptativos son ágiles, iterativos o incrementales. El alcance detalladoiii
se define y
aprueba antes del comienza de una iteración. Según el PMI los ciclos de vida adaptativos
son también llamados ágiles o change-driven.
 Los híbridos son una combinación de predictivo y adaptativo. Los elementos del proyecto
sobre los que se tiene un buen conocimiento siguen el predictivo. Aquellos que no se
conocen bien y evolucionan siguen un desarrollo adaptativo.
La Guía remarca que el administrador de proyecto junto con el equipo de administración de
proyectos determina el ciclo de vida a utilizar para cada proyectoiv
.
También se remarca la importancia de tener en cuenta que los Ciclos de Vida de proyecto son
independientes del Ciclo de Vida del producto.
1.2.4.2. Fases del Proyecto.
Se enfatiza que una fase es una colección de actividades del proyecto relacionadas por una lógica
determinada que culmina al finalizar uno o más entregables. Estas fases se describen por una seria
de atributos medibles y únicos específicos para la fase.
Se incorpora el concepto de “Revisión de la Fase” que da pie a lo que sigue.
1.2.4.3. Phase Gate.
Con esta incorporación se abre la puerta a la definición de modelos de gobierno (governance) en
proyectos y básicamente a lo que se conoce como Modelo Stage-Gate. Según el PMI una actividad
de phase gate se realiza al final de una fase. Con esta actividad el desempeño y el avance del

4. 22 de Septiembre de 2017
www.bawarp.com
Entendiendo la Guía de Administración de Proyectos del PMI® Sergio Luis Conte
P a g e | 4
proyecto se comparan contra los documentos de negocio y se toma una decisión de go/no-go (seguir
adelante o no) v
.
Desde aquí se encontraran con todo aquello que anteriormente formaba parte del capítulo 3 de la
Guia, a saber:
 1.2.4.4. Procesos de la Administración de Proyectos. Señala que un ciclo de vida de proyecto
se administra ejecutando una serie de actividades de administración de proyectos
conocidas como Procesos de Administración de Proyectos. Explica además el formato con
el cuál se describen dentro de la Guía.
 1.2.4.5. Grupos de Procesos de la Administración de Proyectos. Señala que es una
agrupación lógica de los Procesos de la Administración de Proyectos y que son
independientes de las fases del proyecto. Explica la agrupación dentro de la Guía.
 1.2.4.6. Áreas de Conocimiento de la Administración de Proyectos. Señala que cada Área de
Conocimiento es un área identificada dentro de la administración de proyectos definida por
los conocimientos requeridos y descriptos en términos de los procesos, prácticas, entradas,
salidas, herramientas y técnicas que la componen. Muestra una descripción general ya que
en el contenido de la Guía se encuentra todo el detalle.
 1.2.4.7. Datos e Información. Se hace una descripción detallada de todos los datos que se
recolectan a lo largo del ciclo de vida del proyecto para su posterior análisis y publicación.
Lo más importante es la distinción que se hace entre dato, información y reporte. La
distinción de estos conceptos está tomada de la Teoría de la Información de Claude
Shannonvi
. Esta distinción es una directriz a lo largo de la Guía. La figura 1-7 de la Guía
muestra el flujo de datos, información y reporte a través de los grupos de proceso.
1.2.5. Tailoring.
Un concepto que explícitamente se incluye (anteriormente estaba implícitamente incluido) es de
Tailoring. El PMI® señala que los Administradores de Proyecto aplican, usualmente, una
metodología de administración de proyectos al realizar su trabajo.vii
Según la Guía una metodología
es un sistema de prácticas, técnicas, procedimientos y reglas utilizadas por las personas que trabajan
en una disciplina. Esta definición, según el PMI, deja claro que la Guía no es una metodología en sí
misma. Por esta razón se deben seleccionar los procesos, entradas, herramientas, técnicas, salidas
y el ciclo de vida de proyecto para administrar cada proyecto en particular. Esta actividad se conoce
como el “Tailoring de la Administración de Proyectos”. El Administrador de Proyectos colabora con
el equipo del proyecto, el patrocinador (sponsor), el management de la organización en la actividad
de Tailoringviii
. En muchos casos la organización requiere la utilización de una metodología
específica. La Guía hace mención a la necesidad de Tailoring dadas las diferentes condiciones en las
que un proyecto puede desarrollarse teniendo en cuenta el ambiente, la cultura organizacional, las
necesidades de los interesados y otras variables.
1.2.6. Documentos de Negocio de la Administración de Proyectos.
Esta es otro agregado importante en la Guía. Sobre todo lo que se encuentra en la tabla 1-5 y en la
figura 1-8 de la Guía dónde se incorporan las etapas de Pre-proyecto junto con las Gate Phase (ver
referencia anterior al método Stage-Gate). Tener en cuenta la utilización de la palabra “Proyecto”
al nombrarlos. Básicamente se nombran dos documentos principales:

5. 22 de Septiembre de 2017
www.bawarp.com
Entendiendo la Guía de Administración de Proyectos del PMI® Sergio Luis Conte
P a g e | 5
 El Caso de Negocio del Proyecto. Utilizado como base para la autorización del proyecto.
 El Plan de Administración de Beneficios del Proyectoix
. Documento explicando el proceso de
creación, medición y sostenimiento de los beneficios provistos por el proyecto.
1.2.6.1. Caso de Negocio del Proyecto.
Más allá de la incorporación de la definición y del contenido propuesto lo importante a tener en
cuenta es (según la Guía):
 Se utiliza como base para autorizar el proyecto.
 Enumera los objetivos y razones para iniciar el proyecto y por esta razón se utiliza para
medir el éxito del proyecto contra los objetivos del proyecto.
 Se utiliza antes del inicio del proyecto y para tomar decisiones de go/no-go durante la
ejecución (de nuevo referencia al método Stage-Gate) ya que debería contener los objetivos
y los criterios de éxito que puedan ser comparados con los resultados obtenidos durante el
ciclo de vida del proyecto.
Hace referencia explícita a la realización de la actividad “Needs Assessment” que pertenece al
ámbito del Análisis de Negocio remarcando que es allí donde el documento tiene origen, en algunos
casos, como subconjunto de lo expresado en un Caso de Negocio si lo hubiera.
1.2.6.2. Plan de Administración de los Beneficios del Proyecto.
La Guía propone generar este documento adicional (muchos colocan esto directamente dentro del
Caso de Negocio o del Caso de Negocio del Proyecto). Define un “beneficio del proyecto” como “una
salida de acciones, comportamientos, productos, servicios o resultados que provee valor a la
organización patrocinadora (sponsoring organization) como también a los beneficiarios del
proyecto.”. Hace mención a que el desarrollo de los beneficios y de todo lo relacionado con su
generación y medición (la base de este plan) debería desarrollarse en etapas bien tempranas del
ciclo de vida del proyecto.
Según la Guía la base para el desarrollo del Plan de Administración de Beneficios es el Caso de
Negocio y el resultado de la Auditoría de Necesidades (Needs Assessment)x
.
1.2.6.3. Project Charter y Plan de Administración del Proyecto.
No hay diferencias con versiones anteriores respecto de sus definiciones. Solo remarcar que ambos
son documentos, que el Charter debe ser firmado por el patrocinador (sponsor) y que el Charter
entrega al Administrador de Proyectos la autoridad de aplicar los recursos de la organización a las
actividades del proyecto.
1.2.6.4. Medidas de Éxito del Proyecto.
Esta es una sesión que fue repensada y rescrita. Mantiene la idea de que la medida de éxito de los
proyectos debería estar alineadas con lo referente a tiempos, costo, alcance y calidad. Pero agrega
que también hay que considerar los objetivos del proyecto y la visión o expectativas de los
interesados del proyecto. Esto ayuda a considerar el punto de vista del negocio.

6. 22 de Septiembre de 2017
www.bawarp.com
Entendiendo la Guía de Administración de Proyectos del PMI® Sergio Luis Conte
P a g e | 6
BIO del AUTOR.
Sergio Luis Conte, República Argentina
Sergio Luis Conte es Ph.D in Software Engineering egresado de la
Universidad Cargnegie Mellon, USA.
También obtuvo su título de Licenciado en Sistemas de la Universidad
CAECE y realizó estudios de posgrado en Administración y Dirección
Empresarial en la Facultad de Ingeniería de la UBA, en Ingeniería de
Software en la Universidad CAECE y en Ingeniería del Conocimiento
(disciplina base de la Inteligencia Artificial) en el ITBA.
Actualmente trabaja en PepsiCO en el GPMG (Global Project Management
Group) como responsable de Programas para Latino America.
Sergio posee las certificaciones PMP®, PMI-PBA® y PMI-ACP® del PMI®
y CBAP® del IIBA® como así también la AP&C® del DSDM® Consortium.
En el tema Project Management y Business Analysis trabaja con el
PMI® en la generación y revisión de las Guías y Estándares
relacionados como así también con el IIBA® dónde trabajó en el
grupo que dio origen a la disciplina de Business Analysis.
En el tema Agile participó del grupo que dio origen a la práctica (USA
DoD NSF/Agility Forum, 1990 y fue co-author de las versiones 1 y 2
del método DSDM (una de los tres métodos Ágile más citados en la
bibliografía junto con Scrum y XP) trabajando con Arie Van
Bennekum, uno de los creadores del Manifesto para el Desarrollo de
Software Ágil.
En su faz personal, fué jugador de tenis de la ATP y posee la
matrícula profesional Level 1 de la ITF, AAT y USPTA como Profesor
y Entrenador de Tenis.
Para más información sobre sus antecedentes puede consultar:
http://ar.linkedin.com/pub/sergio-luis-conte/19/381/858
i
Bertalanffy Ludwid. Teoría general de los sistemas. Fondo de cultura económica. p. 37. ISBN 968-16-0627-2.
ii
Esto no es correcto. Existen ciclos de vida predictivos como los secuenciales y otros.
iii
Esto no es correcto porque justamente una de las características es que se comienza sin tener un alcance detallado.
iv
Aquí se pierde de vista algo que luego se refuerza en la documentación relacionada con Análisis de Negocio. La selección del ciclo de
vida a utilizar es un tema estratégico y el Analista de Negocio es responsable por liderar el proceso de selección en etapas incluso
anteriores a la aprobación del proyecto.

7. 22 de Septiembre de 2017
www.bawarp.com
Entendiendo la Guía de Administración de Proyectos del PMI® Sergio Luis Conte
P a g e | 7
v
En realidad el método de Stage-Gate es casi un método estándar y en cada punto, con la información de los proyectos/programas
pueden tomarse 4 decisiones básicas. El método tiene muy buenos resultados. Para más referencias pueden consultar www.stage-
gate.com
vi
Teoría Matemática de la Información: http://www.essrl.wustl.edu/~jao/itrg/shannon.pdf
vii
El uso de la palabra “Metodología” es incorrecto. La palabra correcta a utilizar es “Método”. Pero luego de varias discusiones se
acordó utilizar “Metodología” debido al uso común que se hace en forma general.
viii
La selección del ciclo de vida del proyecto es un tema estratégico. La responsabilidad de llevarla adelante recae en el Analista de
Negocio. Existe una actividad relacionada a esto en las guías correspondientes que se realiza en las etapas anteriores a que el proyecto
exista.
ix
Tener en cuenta que los beneficios son alcanzados por el producto/servicio/resultado que el proyecto va a generar, no por el proyecto
en sí mismo. Por esta razón luego se encuentran referencias a los documentos relacionados al Análisis de Negocio ya que es la figura del
Analista de Negocio la responsable de guiar las acciones para la definición del producto/servicio/resultado como así también de las
ventanas de oportunidad y de los costos que se utilizarán como restricciones del proyecto.
x
Ambos absoluta responsabilidad del Analista de Negocio.