REAL

LIFE PROJECT
MANAGEMENT
Un libro de Aplicación del PM
 Real Life Project Management
Por

Federico Vargas Uzaga, DBA, MPM, MBF, PMP®

Prólogo

Por alguna razón, sin duda alguna asociada al ego, a los que nos desarrollamos en el mundo del Project
Management o la Gestión de Proyectos (entiéndase PM para ambas definiciones), nos encanta mostrar
nuestro ejercicio diario, como algo más complejo de lo que realmente es; y ojo, que no pretendo
demeritar la complejidad intrínseca que la gestión de proyectos trae, sin embargo, resulta súper
interesante ver como en el simple ejercicio de la definición de proyecto, ponemos un sinfín de “adornos”
para “demostrar” la magia que como Gerentes-administradores-gestores de proyectos (PMs) debemos
hacer para que las cosas salgan lo más cercanas posibles al plan, o más aún, lo más cercanas a lo que se
le prometió al cliente en la mayoría de los casos sin tan siquiera consultarnos.

Si bien es cierto que el Project Management no es “ciencia de cohetes”, sin lugar a duda si construye
cohetes.

Este documento tiene como objetivo “tangibilizar” los conceptos que podemos encontrar dentro de los
distintos cuerpos de conocimiento que hay disponibles a la fecha de manera global, con especial énfasis
en lo establecido o documentado en el Cuerpo de Conocimiento de la Administración de Proyectos,
PMBOK® Guide por su nombre en inglés, el cual no solo es un estándar de reconocimiento internacional,
sino que además es el cuerpo de conocimientos por “excelencia” del mundo del Project Management
(PM), junto con lo planteado en marcos metodológicos como el de “Projects in Controlled Environments”
(PRINCE2®) y SCRUM® entre otros.

Resulta preponderante aclarar, que nada de lo que explicaremos o desarrollaremos en este documento
es teoría, con excepción de los conceptos relacionados a la gestión de la calidad y los recursos humanos,
que, si contienen teoría de ambas disciplinas, para el resto de áreas los conceptos que desarrollaremos
deben entenderse como mejores prácticas. ¿Cómo se entiende esto?, pues de la siguiente manera, la
academia, viene veinte (20) años detrás de la práctica, esto quiere decir, que de manera intencional el
mundo académico se espera veinte (20) años para comenzar a investigar sobre un tema o práctica
específica; esto lo hace no solo para permitir a dicha práctica adquirir la madurez suficiente, sino para
permitirle a la misma demostrar que no es una simple moda más, sino algo que puede y merece
desarrollarse de manera profesional.

Así, el PMBOK® Guide, que es revisado cada cuatro años, ya se encuentra en su sexta edición, lo que
quiere decir que estamos listos en el mundo, para comenzar la investigación seria, con rigurosidad
académica que se necesita para crear conocimiento dentro del mundo del PM, sin embargo hasta que
ese nuevo conocimiento llegue a las “masas”, podremos verlo reflejado en documentos como este,
mientras tanto, desarrollaremos a profundidad aquí, las mejores prácticas que he citado anteriormente

PMBOK es una marca registrada del Project Management Institute, Inc.

1
junto con lo estipulado o desarrollado en el marco de PRINCE2®, y lo estipulado en el SBOK® (Scrum Body
of Knowledge), Cuerpo de conocimiento de Scrum desarrollado por ScrumStudy®.

Todo lo expresado en este documento, se encuentra fundamentado en los más de 18 años de experiencia
en la administración de proyectos a nivel global, así como en la documentación publicada por fuentes
fidedignas y respetadas del mundo del Project Management.

2
¿Para quién es este libro?

Este libro está escrito pensando en la totalidad de la comunidad del Project Management a nivel mundial,
el lenguaje utilizado, y la forma en que esta desarrollado permitirá al nuevo practicante, comprender de
manera no solo clara y concisa, sino que también correcta, los conceptos, procesos, técnicas y
herramientas, que son responsabilidad de un PM dentro de un proyecto o proyectos. También, será de
gran ayuda para el PM Profesional, sea que cuente o no con una certificación, le permitirá refrescar
conceptos, pero lo que es aún más importante, le permitirá aclarar o corregir algunos que no los tenía
tan claros. Los años de experiencia, formando y entrenando PMs a nivel global en todos los continentes,
me han permitido observar como tenemos muchas prácticas y conceptos que simple y sencillamente los
hemos transmitido de manera incorrecta a través del tiempo; durante mucho tiempo, yo también lo hice
así, y este libro es la evidencia, de que podemos reconocer lo que no hemos hecho bien, a partir de lo
que ahí afuera, otros hacen bien, para aplicarlo y enseñarlo de la manera correcta. Nada de lo que está
escrito en este libro debe de entenderse como LA VERDAD, sino más bien como el mejor esfuerzo del
autor, de reflejar la forma correcta de hacer las cosas, a partir no solo de la validación en la práctica, sino
también de la enseñanza y el intercambio de conocimientos con los que lo están haciendo de la manera
correcta.

¿Por qué leer este libro?

Primero porque es distinto a los otros libros de PM que hay hoy en día; sin duda, todos los autores deben
decir esto, y en cierta medida todos tenemos razón, cada libro es un reflejo de la verdad de cada uno, y
por lo tanto cada uno es distinto, sin embargo, después de revisar mucha de la bibliografía existente en
el tema de PM, tanto es español como en inglés, resulta muy claro que un gran porcentaje de los libros
están estructurados a partir de lo que el Project Management Institute PMI® plantea en el PMBOK®
Guide, y no es que lo que se plantea en el PMBOK® Guide esté mal, es el compendio de mayor
reconocimiento de mejores prácticas de la industria como lo hemos indicado antes, el error no está en
el PMBOK® Guide per se, sino en la interpretación que se hace del mismo. Dicho libro, NO es una
Metodología, NO es prescriptivo, y lo que es aún más importante, los procesos que plantea como
mejores prácticas, no ocurren como está estructurado el estándar, es decir, los capítulos del libro; esto
está explicito dentro del mismo PMBOK® Guide, sin embargo por alguna razón, las personas,
profesionales, docentes, e incluso investigadores, lo interpretan así, de ahí, que por ejemplo se diga que
la gestión de Riesgos es Project Management avanzado, cuando en la práctica, sin una adecuada
planificación de riesgos, resulta prácticamente imposible contar con un cronograma y un presupuesto
que sean congruentes y realistas.

En este libro, encontrarás lo que el autor considera, como aspectos fundamentales, como procesos
críticos y mínimos para una adecuada gestión de tus proyectos, contemplando todas las áreas de
conocimiento que plantea el PMBOK® Guide, aspectos y herramientas que plantea también el SBOK®, la
guía de Scrum, PRINCE2 en su método entre otros, todos desde la perspectiva aplicativa, y no tanto desde
la perspectiva descriptiva o “teórica”.

PMBOK es una marca registrada del Project Management Institute, Inc.

3
Este libro tiene como objetivo, apoyarte en el proceso de convertirte en un practicante del PM.

Sobre mí

El día de hoy puedo decir que cuento con más de 18 años de experiencia práctica en el mundo de la
gestión de proyectos, ocupando posiciones de manera local, regional y global dentro del todo el espectro
del la Gestión de Proyectos empresarial EPPPM por sus siglas en inglés, gestionando Portafolios,
Programas y Proyectos, en Latinoamérica, Estados Unidos, Asia y Europa. Cuento además con mas de
13 años de ejercicio académico, he sido Director de dos programas de Maestría en PM, los primeros dos
Acreditados en Latinoamérica por el Centro Global de Acreditaciones del Project Management Institute
(PMI)®, y actualmente soy parte del cuerpo docente de la UTP y UPC en Perú, UEES en Ecuador, UNITEC
en Honduras, U Latina y UCR en Costa Rica, UB de Argentina y UB de Barcelona. También me desempeño
como Director del Centro Global de Acreditaciones (GAC® del PMI®) desde el año 2015, y desde el año
2017 soy también Director en la Organización Project Management Without Borders y como mentor en
la organización de LINGOs.

He participado en procesos de Acreditación Académica de Programas de Gestión de Proyectos em India,

Estados Unidos, toda Latinoamérica y Europa.

Soy el CEO de Grupo Empresarial 360, donde tenemos como misión Transformar el Mundo, y lo hacemos
por medio de Consultoría, Capacitación y Sourcing en distintas áreas como el PM y Liderazgo, mis dos
pasiones. Nuestra organización existe desde el 2007 y tenemos operación en Costa Rica, Colombia y
Perú.

Mas de 17 años formando Project Managers, ya sea por enseñanza formal o coaching o mentoring, han
sido la principal motivación para escribir este libro, con el objetivo de ayudar a otros a Transformar el
Mundo.

PMI y PMBOK son marcas registradas del Project Management Institute, Inc.

4
Índice

Capítulo 1: ¿Producto o Proyecto? ........................................................................................................... 7

El ciclo de vida del Producto y del Proyecto......................................................................................... 11
Capítulo 2: El Rol del Project Manager ................................................................................................... 17
Organización Funcional o Proyectizada................................................................................................ 18
¿Proyectos Internos o del Cliente? ...................................................................................................... 23
¿Qué NO es un PM? ............................................................................................................................. 25
Competencias Básicas de un PM .......................................................................................................... 25
Señorío (Seniority) y Experiencia vs Certificación ................................................................................ 28
Capítulo 3: Los trabajos (esfuerzos) dentro del Proyecto ...................................................................... 30
Capítulo 4: La Gestión de Proyectos (Project Management) ................................................................. 34
Etapa de Inicio ...................................................................................................................................... 38
Etapa de Planificación .......................................................................................................................... 38
Etapa de Desarrollo .............................................................................................................................. 41
Etapa de Cierre ..................................................................................................................................... 44
Áreas de Conocimiento – Aspectos - Temas de Gestión ..................................................................... 45
Las etapas o actividades previas al proyecto ....................................................................................... 47
El Rol de las Oficinas de Proyectos ....................................................................................................... 51
Capítulo 5: Comprendiendo los procesos de Gestión básicos o fundamentales ................................... 53
Etapa de Inicio ...................................................................................................................................... 53
Etapa de Planificación .......................................................................................................................... 57
Capítulo 6: El Marco de Referencia del Project Management Institute (PMI®) .................................... 82
Grupos de Procesos de Dirección de Proyectos.................................................................................. 85
Grupo de Procesos de Inicio:............................................................................................................ 85
Grupo de Procesos de Planificación: ................................................................................................ 85
Grupo de Procesos de Ejecución: ..................................................................................................... 86
Grupo de Procesos de Monitoreo & Control: .................................................................................. 86
Grupo de Procesos de Cierre:........................................................................................................... 87
Áreas de Conocimiento de la Dirección de Proyectos ........................................................................ 88
Capítulo 7: Proyectos en ambientes controlados (PRINCE2®) ............................................................... 91

5
Capítulo 8: Agile Project Management y el Marco de Referencia del Scrum® ...................................... 92
Capítulo 9: El Dilema del Líder – PM ....................................................................................................... 93
Capítulo 10: Gestión de Programas de Proyectos .................................................................................. 94
Capítulo 11: Gestión de Portafolios de Proyectos .................................................................................. 95

6
 Capítulo 1

¿Producto o Proyecto?

Para poder desarrollar los conceptos de gestión de proyectos (PM), resulta crítico comenzar por el
principio. Las estadísticas que el Project Management Institute (PMI)® publica de manera anual en
el Pulso de la Profesión (Pulse of the Profession®), el cual resulta ser el documento global principal
de estadísticas y hallazgos en el mundo profesional del PM, muestran año a año, cifras alarmantes
en lo que respecta a la cantidad de proyectos que resultan o son considerados exitosos, y lo que
resulta aún más alarmante, es el hecho de la mayoría de los proyectos que fallan, fallan porque el
gerente o administrador, director, responsable del mismo, no ha tenido claridad del producto y del
proyecto como tal.

Habiendo dicho esto pondremos especial énfasis en exponer los conceptos arriba citados, buscando
lograr que usted que está leyendo, al finalizar este capítulo tenga una clara concepción de los
distintos conceptos y las características que diferencian a uno del otro.

Un proyecto, puesto de la manera más sencilla, es ALGO que debo hacer para poder obtener otro
ALGO. El primer algo se refiere al esfuerzo que debo realizar para poder hacer una realidad el
segundo algo; al primero se le conoce como PROYECTO y al segundo se le conoce como PRODUCTO.
La persona responsable de que el proyecto se realice NO puede no tener claridad sobre estos dos
conceptos, y más aún, no puede aducir desconocimiento de lo que ambos implican o contemplan.

En A Guide to de Project Management Body of Knowledge- Fifth Edition (PMBOK® Guide), un

proyecto se define como un “esfuerzo temporal que se lleva a cabo para crear un producto, servicio
o resultado único” (PMI, 2017:XX), lo cual, de manera sencilla nos permite identificar la relación que
existe entre los dos conceptos; sin proyecto NO hay producto, sin la ejecución de ese esfuerzo, el
producto NO existirá o no será una realidad.

Nótese en la frase anterior, que hemos, de manera intencional resaltado la palabra temporal, esto,
debido a que, dicha temporalidad es algo propio que comparten TODOS, absolutamente TODOS los
proyectos sin excepción. Un proyecto se diferencia de la operación normal de cualquier organización
por el simple hecho de que nace y muere, es decir, es temporal.

PMI y PMBOK son marcas registradas del Project Management Institute, Inc.

7
Ahora bien, hemos indicado que lo que tienen en común todos los proyectos es esa temporalidad,
sin embargo, de la misma frase podemos rescatar otra cuestión muy importante, que nos servirá
también para desarrollar el concepto siguiente; de la frase en cuestión, podemos y debemos inferir,
que TODOS los proyectos TIENEN el mismo objetivo; y ese objetivo es crear o entregar un producto,
servicio o resultado único. De manera errónea, en la práctica se le atribuyen a los proyectos, los
objetivos de los productos, y como veremos en breve, estos si son muy variados según el producto,
y son precisamente los que justifican el desarrollo de los proyectos como tal.

El producto es resultado del proyecto como lo hemos visto, y es lo que le permite a la organización
resolver el problema que enfrenta o aprovechar la oportunidad que ha identificado.

***Figura ciclo vida del proyecto**** FALTA LA IMAGEN CORREGIDA

8
Así, podemos observar que los proyectos existen porque se ha identificado una necesidad o
problema dentro de una organización, porque además se ha identificado un producto, servicio o
resultado que le permitirá a la organización resolver dicho problema, y porque se ha aprobado un
presupuesto para que el esfuerzo necesario (Proyecto) se realice para hacer realidad el producto,
esto debido a que existe una “Justificación de Negocio” para realizar dicho gasto o inversión; dicho
de otra manera, porque existe un Caso de Negocio, en el que los beneficios que generará el
producto del proyecto, son mayores que los gastos/inversión que debo utilizar para desarrollar el
proyecto.

***Figura procesos previos al proyecto**** FALTA LA IMAGEN CORREGIDA

Todos esos procesos citados, ocurren antes de que el proyecto exista, esto quiere decir, que la
organización que sufre el problema o identifica la oportunidad, debe realizar todo ese trabajo para
llegar a tomar la decisión de hacer el proyecto; muchos “proyectos”, que realmente son ideas o
iniciativas nunca concluyen esta etapa previa, se cancelan, o abandonan a partir de los resultados
de las mismas. La experiencia nos dice que, de manera errónea, más del 80% de las organizaciones,
clasifican esas iniciativas o ideas como proyectos, cuando realmente no son más que ideas que aún
no tienen un presupuesto asignado, ideas que aún no han demostrado generar más beneficios que
gastos, por lo que resulta no solo erróneo, sino imposible llamarlos proyectos.

Para que una idea/iniciativa se vuelva o transforme en proyecto, es NECESARIO que exista un
acuerdo/contrato que estipule y determine la temporalidad y los recursos disponibles para el
mismo.

9
Sin acuerdo o contrato entonces, NO HAY PROYECTO.

Podemos observar también, otro aspecto fundamental, que resulta ser también una de las
principales causas de fracaso en los proyectos, y esta se refiere a una mala definición del producto
como tal; de lo expuesto hasta el momento, se puede determinar o inferir que el Proyecto es
función del Producto, es decir, que las características del producto, determinarán el esfuerzo que
debo realizar para crearlo, así el proyecto varía en función de cómo varíe el producto.

Ahora bien, ¿que entendemos por producto?

En el PMBOK® Guide, el producto se define como “un componente de otro elemento, una mejora
de un elemento, o un elemento en sí mismo”, “un servicio o la capacidad de brindar un servicio (p.
ej. una función de negocio que brinda apoyo a la producción o distribución”, “una mejora de las
líneas o productos existentes” (PMI, 2017).

Así como el proyecto es función del producto y sus características, estas características son a su vez
función del problema u oportunidad que trato de resolver o aprovechar, por lo tanto, las
características del problema determinan nuestra idea del producto, lo que a su vez impactará o
determinará la idea del proyecto que tengamos.

Un buen Project Manager (PM), no es realmente el que es un experto en los estándares que veremos
en este documento, el conocimiento de dichas mejores prácticas no es suficiente para serlo; un
buen PM es más bien aquel que aparte de ser un experto en las mejores prácticas, tiene claridad de
cómo es el producto que debe entregar, que problema resuelve este producto, y que nivel de
esfuerzo debe la organización de la que él o ella será responsable, ejecutar, es decir, cual es el
proyecto que debemos hacer. De poco servirán las mejores prácticas y herramientas de gestión para
iniciar, planificar, dirigir, controlar y cerrar, si no se tiene claridad del producto que se debe entregar,
las razones por las que se entregará, y el esfuerzo que debo hacer.

Solo teniendo la claridad indicada, entiéndase conocimiento y certeza del producto, entonces, esas
mejores prácticas y herramientas agregarán muchísimo valor al proceso de gestión, y sin duda,
como está debidamente documentado y demostrado, aumentarán las probabilidades de éxito del
proyecto como tal.

PMBOK es una marca registrada del Project Management Institute, Inc.

10
El ciclo de vida del Producto y del Proyecto

Tanto el producto como el proyecto tienen un ciclo de vida, es decir, ambos nacen y mueren, tienen
un inicio y un fin; como hemos discutido con anterioridad, el proyecto es necesario para la existencia
del producto, con el desarrollo del proyecto, se construye el producto, o se mejora un producto
existente.

Refiriéndonos al proyecto en primera instancia, el mismo contempla cuatro etapas muy claramente
definidas, las cuales son las mismas para TODOS los proyectos; estas etapas o fases son:

1. Inicio – Definición
2. Planificación – Organización
3. Desarrollo – Ejecución del trabajo
4. Cierre – Conclusión y transición a operaciones

*****Figura del Ciclo de Vida del proyecto****** FALTA IMAGEN CORREGIDA

Fase de Inicio – Definición:

Aquí es cuando el Project Manager entiende el producto que debe entregar y define el esfuerzo de
manera general para obtener dicho producto, así mismo, con esta definición inicial es que

11
determinamos quienes son los interesados del proyecto, es decir, todas aquellas personas u
organizaciones que puedan verse afectadas por el desarrollo del proyecto o por la utilización del
producto, y que por ende entonces puedan afectar el proyecto como tal.

Posteriormente, una vez que se concluye la fase inicio, es decir que como PM tenemos claridad de
lo que debemos entregar, de lo que debemos hacer, y de quienes se pueden ver afectados,
entramos en la fase de Planificación-Organización

Fase de Planificación-Organización:

Aquí es donde procedemos a definir detalladamente todos los aspectos necesarios para la
consecución del proyecto, dentro de los cuales se encuentran, la correcta definición del trabajo que
debemos realizar, la identificación de los posibles riesgos asociados a dicho trabajo, la definición de
roles y responsabilidades, la programación, estimación y validación de tiempos y costos asociados
al trabajo, la identificación de los criterios de aceptación del o los productos del proyecto, así como
los estándares de calidad asociados, la determinación de los medios y tipos de comunicación y la
identificación de terceros y tipos de contratos asociados a la adquisición de los bienes o servicios
que ellos provean.

Una vez aceptado el plan por parte de nuestro cliente, podemos entonces iniciar con la ejecución
del trabajo del proyecto que definimos y planificamos en las etapas previas, es decir, comenzamos
con la fase o etapa de Desarrollo – Ejecución del trabajo

Fase o etapa de Desarrollo – Ejecución del trabajo:

En esta etapa es en la que produciremos y entregaremos todos los entregables del proyecto. En esta
etapa nuestro trabajo como PMs será el de Dirigir y Controlar la ejecución de dicho esfuerzo, con el
objetivo último de lograr la aceptación satisfactoria por parte de nuestro cliente de todos los
entregables producidos y entregados.

Esta etapa resulta importante discutirla, ya que usualmente es esta etapa o fase la que le da el nombre
al proyecto, es la que enmarca el trabajo de entrega, y por lo tanto es a la que se le suele dar mayor
importancia y visibilidad.

Otra característica de esta etapa, es que suele ser específica de la industria, esto quiere decir, que según
la industria en la que nos encontremos, así encontraremos no solo la cantidad de particiones que puede
tener esta etapa en sub etapas o sub fases, sino que también encontraremos nombre distintos para los
esfuerzos, nombres como Transición, Transformación, Implementación, Construcción, Migración,
Transferencia, Desarrollo, etc.

12
Otro aspecto sumamente importante, especialmente en el entorno actual donde se habla de desarrollo
ágil vs tradicional, es el hecho de que precisamente los métodos de desarrollo y las estructuras del
mismo, son propias de esta fase, aquí podemos encontrar los métodos de desarrollo ágil, así como el
método de desarrollo de cascada (Waterfall). Sin embargo no solo estos, sino que la aplicación de los
ciclos iterativos, incrementales, predictivos y secuenciales, también, así como métodos específicos como
Lean Six Sigma y otros.

Es decir, en esta etapa, en la que se desarrolla el trabajo de entrega, es donde veremos metodologías,
prácticas, sistemas y otros para llevar a cabo dicha entrega, todo con el objetivo de lograr la aceptación
del cliente de las entregas definidas para el proyecto.

Logrado lo anterior, es decir, contando con la “bendición” y aceptación del cliente, inicia entonces la fase
de Cierre – Conclusión y transición a operaciones.

Fase de Cierre – Conclusión y transición a operaciones:

En esta etapa, es cuando se liberan los recursos, se cierran contratos, se documentan lecciones
aprendidas y entregamos/transicionamos el producto al cliente o a la operación, para posteriormente
cerrar formalmente el proyecto.

Una vez transicionado el producto, el proyecto muere, es decir finaliza su ciclo de vida, lo que da inicio
al ciclo de vida del producto, el cual, suele ser bastante más extenso que el del proyecto, y contempla
etapas distintas a las citadas, las cuales NO son responsabilidad del PM.

Acá resulta muy importante indicar, que el ciclo de vida del proyecto, se estructura según la industria en
la que se esté desarrollando el mismo, así como por el marco de referencia o metodológico que decida
utilizarse.

Así, por ejemplo, PRINCE2® define dos etapas como mínimo que deben estar presentes en TODO
proyecto, siendo estas Inicio e Implementación. Precisamente en la segunda, es donde el ciclo de cada
industria se desarrolla.

13
Por otro lado, en Scrum podemos ver un planteamiento un podo distinto, dentro del cual, se
planteas 5 etapas, siendo estas:

1. Inicio
2. Planificación & Estimación
3. Implementación
4. Revisión & Retrospectiva
5. Liberación

Las etapas 2 a 4 son iterativas y se realizarán tantas veces como se defina en la etapa de inicio.

14
Debido a la existencia de los distintos marcos de referencia, resulta crítico para un PM tener claridad
del Ciclo de Vida como tal, el cual es uno como citamos, pero se ve afectado, no solo por la industria
en la que se desarrolle el proyecto, sino también, por el marco metodológico que se utilice para
gestionarlo, sea uno de los citados con anterioridad, o sea el propio de la organización, ya que si no
puede caer en el error de pensar que dicho marco metodológico es un reflejo del ciclo de vida, lo
que sería perjudicial para el proyecto como tal.

Un aspecto importante a recalcar, es que, durante el ciclo de vida del producto, pueden surgir varios
proyectos, asociados a la mejora, actualización, renovación del producto en cuestión, lo que quiere
decir, que, dentro del ciclo de vida del producto, podríamos tener varios ciclos de vida del proyecto.

15
16
 Capítulo 2

El Rol del Project Manager

El Project Manager (PM), o gestor-administrador-gerente de proyectos, es la persona responsable

última del éxito del proyecto. Su trabajo está definido por los procesos de gestión de proyectos, y
como tal su responsabilidad es la de Iniciar, Planificar, Dirigir, Controlar y Cerrar, el proyecto y cada
una de sus etapas.
Todo PM, NO es responsable de ejecutar el trabajo de entrega, es decir, el trabajo que produce el
producto, pero si es responsable de que dicho trabajo se desarrolle de manera correcta y exitosa
por parte de los miembros del equipo del proyecto.
Cómo bien indicamos con anterioridad, el PM DEBE ser un experto en el Producto que su proyecto
debe entregar, ya que solo de esta manera podrá definir, junto con su equipo, el esfuerzo necesario
para entregarlo, es decir el Proyecto.
Cuando decimos experto en el producto, debe entenderse como alguien que conoce de “al dedillo”
el producto que el proyecto debe entregar, y NO como que es experto en el desarrollo de dicho tipo
de producto o servicio, lo segundo es sin duda un valor agregado para el proyecto y la gestión del
mismo, más no algo NECESARIO y/o Obligatorio. De hecho, por error, muchas organizaciones
asignan a un experto desarrollador como PM, solo por su conocimiento del desarrollo del tipo de
producto o servicio, sin validar su expertise y conocimiento en gestión/dirección de proyectos, y los
resultados, rara vez son positivos.
Así, podemos concluir, que el PM es responsable del trabajo de administración/gestión, mediante
el cual, propicia la correcta ejecución de los trabajos de entrega y apoyo, lo que aumenta la
probabilidad de tener un proyecto exitoso.

17
Organización Funcional o Proyectizada

A pesar de lo descrito anteriormente, muchos lectores o PMs estarán en este momento pensando,
que esa definición es muy “teórica” y que en la “vida real” esta no aplica.
Esto probablemente se deba al hecho, de que quien haga dicho comentario pertenezca a una
organización funcional, es decir, una organización, cuyo “Core Business” No es en efecto el
desarrollo de Proyectos; o quizás porque el nivel de madurez en temas de Project Management en
su organización es bajo. Ambos casos son reflejos de la “realidad” de la mayoría de PMs a nivel
global, sin embargo esto no quiere decir que la definición provista sea incorrecta.
La responsabilidad de un PM es la misma, indiferentemente del tipo de organización en la que él o
ella se encuentre, esto quiere decir que más allá de lo que “pueda” hacer en mi organización,
realmente se trata de lo que debo hacer en mi organización.
Las mejores prácticas de gestión, las cuales se encuentran documentadas en varias publicaciones
por entes que están a la vanguardia en el tema de Gestión de Proyectos, entre ellas, la publicación
conocida como “El Cuerpo de Conocimiento del Project Management” (PMBOK® Guide), del PMI®,

18
“Projects in Controlled Environments” (PRINCE2®), “El Cuerpo de Conocimiento de Scrum” (SBOK®),
de ScrumStudy®, “La Guía de Referencia para la Sostenibilidad en la Dirección de Proyectos” de
Green Project Management Global (GPM®), el IPMA Competence Baseline (ICB) for Project
Management, y la Norma ISO 21500, las cuales desarrollaremos en este texto, son aplicables en
cualquier tipo de organización, y en cualquier tipo de proyecto, no son prescriptivas, y solo algunas
son una metodología (PRINCE2® y SCRUM®), como erróneamente se conciben. Las metodologías
son propias de cada organización, y estas, son precisamente el resultado del encuentro de dichas
mejores prácticas, con la cultura y procesos de la organización en cuestión.
Habiendo aclarado eso, conviene mencionar los distintos tipos de organización que la teoría define:

PMI y PMBOK son marcas registradas del Project Management Institute, Inc.

19
 Organización Matricial Débil

Organización Matricial Equilibrada

20
 Organización Matricial Fuerte

Organización Orientada a Proyectos

21
De acuerdo a la figura, cada quien podrá identificar el tipo de organización a la que pertenece, una tarea
básica y crítica que el PM debe realizar para poder desarrollar a plenitud su rol.
Dentro de una organización Funcional, la autoridad que tendrá el PM será prácticamente NULA, por lo
que realmente fungirá como facilitador de los procesos de la ejecución durante el ciclo de vida, sin
embargo, esto no quiere decir, que como facilitador no pueda comenzar a implementar algunas, sino
todas las mejores prácticas y herramientas de las que hablaremos y desarrollaremos en el texto.
En una organización Matricial Débil, la función del PM será de Coordinador, en este caso tendrá un poco
más de autoridad que en la organización funcional, más sin embargo, siempre estará supeditado a la
autoridad del líder o gerente funcional, así como los recursos asignados al proyecto.
Ya en la organización Matricial, la autoridad sobre los recursos, comienza a distribuirse y la misma se
comparte en partes “iguales” con el Gerente o líder funcional, por lo que el rol del PM si será más cómo
el de gerente o gestor.
Finalmente en las organizaciones Matricial Fuerte y Proyectizadas, el PM tiene completa autoridad para
la toma de decisiones con respecto a los recursos y presupuesto del proyecto.
Nótese sin embargo, que indiferentemente del tipo de organización, debe haber alguien responsable de
asegurar que el proyecto transicione de una etapa a la siguiente de manera correcta y en el momento
correcto, y el único responsable puede y debe ser el PM, sin importar si es un “facilitador”, “coordinador”
o “gerente”.

22
¿Proyectos Internos o del Cliente?

Existe otro aspecto del contexto de cada proyecto, que resulta indispensable tenerlo muy claro para una
correcta gestión, y este es, el tipo de proyecto en el que estemos involucrados o debamos gestionar.

Oliver Lehman describe muy claramente las principales diferencias entre uno y otro, y como podemos
ver en la siguiente imagen desarrollada a partir de los planteamiento de Lehman, la gestión se ve
influenciada y afectada de manera significativa por estas características.

** FALTA TABLA EN ESPAÑOL**

23
Figura xxx: Tomado de Project Business Management, ISBN: 978-1138197503

FALTA CAMBIAR A TABLA EN ESPAÑOL

24
Estos aspectos contextuales, relacionados al tipo de proyecto, y al tipo de organización en la que se esté
realizando o se vaya a desarrollar el proyecto, nos permiten comprender la importancia de la formación
y conocimiento integral que debe poseer un PM, entendiéndose este como técnico para los aspectos de
gestión, estratégico para los aspectos políticos y de gestión de interesados o stakeholders, y líderazgo
para los aspectos relacionados al tipo de organización y la autoridad del PM como tal.

¿Qué NO es un PM?

Constantemente encontramos en nuestro ejercicio de consultores y formadores en el tema de

Portfolio, Program y Project Management (PPPM), personas que comienzan a desarrollarse en el
mundo del PM, que se certifican o que les dan la posición de PM, y que por lo tanto interpretan y
creen que de repente son “GERENTES”, y que por ende tiene autoridad no solo sobre el proyecto,
sino sobre las personas que están asignadas al mismo, y sobre los Gerentes Funcionales. Esto es
incorrecto y perjudicial no solo para el PM sino para el proyecto como tal.
Un PM es el Gerente del Proyecto, es responsable como hemos indicado, de gestionar el proyecto
durante TODO su ciclo de vida, mas NO es el Gerente de las personas que están asignadas, ni
Gerente de la Organización en lo que respecta a alguna funcionalidad.
Algo que tampoco es el PM, es un experto técnico sobre el trabajo que el proyecto ejecuta, como
se ha indicado anteriormente, si tiene conocimiento y expertise en el tema, esto será un valor
agregado, mas NO un requisito para su gestión, un PM es un EXPERTO en las características del
producto que debe entregar, como bien lo indicamos antes, así como un experto en la técnicas,
herramientas y procesos que son necesarios para administrar o gestionar el proyecto, y para ello
DEBE contar con una serie de competencias claramente definidas para ello.
Por otro lado, un PM tampoco es el Gerente o Gestor de Programas, ni mucho menos de Portafolios, ya
que como veremos más adelante, las competencias requeridas para cada una de estas posiciones o roles,
son muy distintas a las que requiere o debe tener un PM.

Competencias Básicas de un PM

El PMI®, luego de años de análisis y definición del rol de un PM de manera global, creó lo que se
conoce como el Triángulo de Talento del Project Manager (PM Talent Triangle®)

PMI es una marca registrada del Project Management Institute, Inc.

25
Como puede observarse en la figura, un PM DEBE reunir una serie de competencias enfocadas
principalmente en tres ejes fundamentales:
1. Competencias Técnicas en Project Management (procesos, herramientas y técnicas
expuestas en este libro, tomadas de estándares y prácticas profesionales).
2. Competencias de Liderazgo (Habilidades “blandas”, consciencia de sus relaciones)
3. Competencias de Negocio y Estratégicas (Habilidades de consciencia organizacional
(cultura y tipo de organización, giro del negocio, industria, ubicación del proyecto
dentro de la organización, etc)

Algo bastante similar se plantea la Asociación Internacional de Project Management (IPMA®) en su IPMA
ICB® (Individual Competence Baseline), donde plantea tres tipos de competencias básicas para un PM,
siendo estas:

1. Competencias de personas, relacionadas a las competencias personales e interpersonales

requeridas para participar o liderar de manera exitosa un proyecto, programa o portafolio.
2. Competencias de práctica, se refiere a los métodos, herramientas y técnicas utilizadas en
proyectos, programas y portafolios para lograr su éxito

PMI y el Triángulo del Talento son marcas registradas del Project Management Institute, Inc.

26
 3. Competencias de perspectiva, las cuales se refieren a los métodos, técnicas y herramientas
por medio de las cuales los individuos interactúan con el entorno, así como las razones que
llevan a las personas, organizaciones y a la sociedad a iniciar y sostener proyectos,
programas y portafolios.

Cada una de estas competencias son realmente un conjunto, lo que quiere decir que existen una cantidad
de competencias definidas en cada grupo, de esta manera:

1. Competencias de Perspectiva:
a. Perspectiva 1: Estrategia
b. Perspectiva 2: Gobernabilidad, estructuras y procesos
c. Perspectiva 3: Cumplimiento, estándares y regulaciones
d. Perspectiva 4: Poder e interés
e. Perspectiva 5: Cultura y valores
2. Competencias Personales:
a. Persona 1: Auto reflección y auto gestión
b. Persona 2: Integridad y confiabilidad
c. Persona 3: Comunicación personal
d. Persona 4: Relacionamiento e involucramiento
e. Persona 5: Liderazgo
f. Persona 6:Trabajo en equipo
g. Persona 7: Conflicto y crisis
h. Persona 8: Disponibilidad
i. Persona 9: Negociación
j. Persona 10: Orientación a resultados
3. Competencias de práctica:
a. Práctica 1: Diseño
b. Práctica 2: Metas, objetivos y beneficios
c. Práctica 3: Alcance
d. Práctica 4: Tiempo
e. Práctica 5: Organización e información
f. Práctica 6: Calidad
g. Práctica 7: Finanzas
h. Práctica 8: Recursos
i. Práctica 9: Adquisiciones
j. Práctica 10: Planificación y Control
k. Práctica 11: Riesgo y oportunidad
l. Práctica 12: Interesados
m. Práctica 13: Cambio y transformación
n. Práctica 14: Selección y balance

27
Como puede observar, estas últimas, son muy similares a los procesos de gestión y áreas de
conocimiento que plantea el PMI® en el PMBOK® Guide.

Por otro lado, el Centro Global de Acreditaciones para programas académicos de Gestión de
Proyectos, Global Accreditation Center (GAC®), ha establecido también tres áreas de foco:

1. Experiencia Técnica en la gestión de proyectos para cumplir con las restricciones,

referenciado a estándares y guías profesionales.
2. Comportamiento profesional, gestión de interesados, comunicación, liderazgo y trabajo
en equipo, con consciencia ética y cultural.
3. Consciencia Estratégica, consciencia del contexto y conocimiento de los propulsores
estratégicos y operacionales requeridos para informar decisiones y entregar una ventaja
competitiva sostenible.

Así, el camino de desarrollo y formación como PM, es un camino largo que requiere mucho esfuerzo
y dedicación de quien quiera ser PM, una preocupación real por mejorar, desarrollar y pulir las
competencias citadas arriba, para poder así Transformar el Mundo con su ejercicio profesional.

De hecho, quien esté leyendo este libro y ya sea un Profesional en Project Management Certificado
(Project Management Professional-PMP®, PRINCE2, PROJECT+, IPMA), estará de acuerdo en que la
obtención de su certificación como fue SOLO el comienzo de su desarrollo profesional en el mundo
del PM, y, para quien este libro sea su primer contacto con el mundo del PM, esperamos, que el
mismo le abra los ojos y le permita comprender que dicha Certificación, como cualquier otra, es
algo para “comenzar”, y necesaria para poder competir en dicho mundo.

Señorío (Seniority) y Experiencia vs Certificación

El señorío/antigüedad o seniority como se le conoce en inglés, es el concepto de una persona

teniendo precedencia sobre otras por su edad o porque ha ocupado una posición por un periodo de
tiempo mayor que las otras.
En nuestro caso, quisiera referirme a la segunda parte de la definición, para aclarar un concepto que
ha venido siendo interpretado erróneamente por el mercado en general, y este está relacionado a
el seniority que brinda una certificación.
Primero que nada, resulta primordial aclarar que para cada certificación que existe en el mercado,
el ente certificador, define, en la mayoría de ocasiones, una serie de criterios mínimos de
elegibilidad para optar por la misma, siendo la experiencia/seniority uno de ellos; así, NO debe
interpretarse dicha certificación como algo que aporta seniority a una persona, sino más bien como
algo que CERTIFICA la experiencia que dicha persona tiene, la que el ente certificador haya definido.

PMP, PMBOK y GAC son marcas registradas del Project Management Institute, Inc.

28
Por ejemplo, para la certificación Project Management Professional (PMP®), que es la más
reconocida del mercado a nivel global, el requerimiento de entrada es de 3 años de experiencia, de
ahí que la pregunta en una entrevista, quizás deba cambiar de ¿cuántos años de experiencia tiene
usted? a ¿hace cuántos años es usted PMP®?
Un PMP® que sostiene su certificación en el tiempo, es entonces alguien con seniority, experiencia
y con conocimiento actual que le permitirá a la organización y proyectos a los que pertenece, contar
con mayores probabilidades de éxito.

PMP es una marca registrada del Project Management Institute, Inc..

29
 Capítulo 3

Los trabajos (esfuerzos) dentro del Proyecto

Un proyecto es un esfuerzo temporal para entregar un producto, como ya lo hemos mencionado,

ahora bien, un esfuerzo es un trabajo, y como tal, en un proyecto resulta indispensable para un PM
comprender los tres tipos de trabajo que ocurren dentro del mismo, y como la gestión se relaciona
con cada uno de estos trabajos.

30
Como puede observarse en la figura arriba, dentro del esfuerzo temporal tenemos en realidad tres
tipos de esfuerzos o trabajos que ocurren durante el ciclo de vida del proyecto:

1. Trabajo (Esfuerzo) Administrativo: Propio del PM, y sobre el cual desarrollaremos los
capítulos siguientes. Este trabajo es realizado directamente por el PM o por el equipo de
Gestión en proyectos complejos en cuanto a estructura organizacional. Para este tipo de
trabajo es que existen o aplican los marcos de referencia a los que nos referimos acá
(PMBOK® Guide, ISO 21500, IPMA), así como las metodologías que citamos (PRINCE2®,
SCRUM®), el mismo ocurre durante TODO el ciclo de vida del Proyecto, desde la autorización
del mismo, hasta su cierre.
2. Trabajo (Esfuerzo) de Entrega: Este es el esfuerzo más visible, y también el que consume la
mayor cantidad de recursos y tiempo del proyecto, es realizado por el equipo del proyecto,
y, además, es el que es propio de cada industria; así, cada organización y cada industria,
tienen sus métodos propios y sus estructuras de trabajo propias para el desarrollo de este
esfuerzo. Este ocurre durante la etapa de desarrollo del proyecto.
3. Trabajo (Esfuerzo) de Apoyo: “no son exclusivos de la dirección del proyecto, proporcionan
apoyo relevante y valioso para poder producir y dirigir” (ISO, 2015) el trabajo del proyecto.
Este ocurre desde la etapa de planificación hasta el cierre del proyecto y es ejecutado por
miembros de las áreas funcionales de la organización que apoyan el proyecto (RRHH,
Logística, Legal, Compras, etc).

El comprender bien estos distintos esfuerzos, le permitirá al PM no solo asignar responsabilidades

de la manera correcta, sino que también le ayudará en los procesos de identificación de riesgos.

La siguiente figura nos permitirá comprender desde la perspectiva del consumo de recursos, y la
entrega de productos, porqué la etapa de Desarrollo resulta ser las más visible y crítica para nuestros
interesados, principalmente nuestro cliente y nuestro patrocinador, pues uno recibe el producto,
mientras que el otro realiza el gasto, sin embargo como veremos en el siguiente capítulo, para el
PM, la etapa de Planificación es INDISPENSABLE y por ende la más crítica para poder contar con
bases para la Dirección y Control.

PMBOK es una marca registrada del Project Management Institute, Inc..

31
Un aspecto muy interesante que podemos rescatar de la figura son los tiempos aproximados por
etapa, junto con el consumo de recursos por cada una; se puede observar como para la etapa de
inicio, que tiene una duración de aproximadamente +/- 2% del Tiempo total del Proyecto, tenemos
solo un esfuerzo administrativo, es decir está solo el/la PM o el equipo de gestión si este se amerita.
Por otro lado, podemos observar como para la etapa de Planificación, que abarca aproximadamente
un +/-10% del Tiempo total del Proyecto, tenemos un esfuerzo administrativo, en conjunto con un
esfuerzo de apoyo, necesario para poder determinar los tiempos y recursos necesarios para las
actividades de apoyo que serán requeridas tanto en el desarrollo como en el cierre; avanzando hacia
la etapa de desarrollo, la cual consume alrededor de un 85% del tiempo total del proyecto, tenemos
la totalidad de esfuerzos presentes, administrativos, de apoyo y de entrega, lo que en efecto hace
que nuestra curva de costos tenga un salto tan pronunciado, y lo que sin duda, hace que toda la
atención se le ponga a esta etapa. Por último, tenemos la etapa de Cierre, donde tenemos esfuerzos
de administración y de apoyo por aproximadamente un 3% del tiempo total del proyecto.

Esta figura muestra un sinnúmero de aspectos o situaciones que hacen o inducen a que los
proyectos fallen, dentro de las que podemos citar:

1. Pensar que el desarrollo cuenta con un 100% del tiempo total del proyecto, y reflejarlo de
esa manera en el cronograma, creando un cronograma que, de inicio tiene un “atraso” del
15%.
2. Saltarnos el inicio y la planificación para comenzar a ejecutar pues es lo más crítico para mi
cliente y para mi patrocinador, llevándonos a una situación incluso peor que la anterior, ya

32
 que, en este caso, ni siquiera tenemos noción de que tan “atrasado” o comprometido está
nuestro proyecto de entrada.
3. Cometer el error de no involucrar las áreas de apoyo en la planificación del proyecto, lo que
nos lleva a involucrarlas solo cuando se “necesitan” en la ejecución, creando desfases,
atrasos e incluso cancelaciones de proyecto.
4. No considerar expertos en las áreas de esfuerzo correspondiente, para el desarrollo de cada
trabajo. Tan importante es el expertise en compras, legal o Project Management, como lo
es el área técnica del core business de mi organización, o del proyecto (entrega).

33
 Capítulo 4

La Gestión de Proyectos (Project Management)

En los capítulos anteriores, hemos definido los conceptos básicos de la profesión, entiéndase,
proyecto vs producto, ciclo de vida del proyecto, el rol del Project Manager, las competencias
mínimas necesarias, así como las responsabilidades de dicho rol.
Precisamente, de la definición del rol y sus responsabilidades, podemos inferir los procesos que
conforman el Ciclo de vida de la Gestión de Proyectos, el cuál NO debe confundirse con el Ciclo de
Vida del proyecto que citamos anteriormente.
El ciclo de Vida de la Gestión de Proyectos, el cual contiene TODO el trabajo que el PM debe realizar,
ya sea por su propia cuenta o con un equipo de gestión, dependiendo de la cantidad personas
involucrada en el proyecto, según lo que establecen las mejores prácticas de gestión de personas,
algo que comentaremos en la sección de la Gestión de Recursos, más adelante; así, como podemos
observar en la siguiente figura, el ciclo de vida de la gestión de proyectos está conformado por cinco
(5) grupos de procesos, según lo estipulado por el PMI®, que permiten al PM llevar a cabo el
proyecto de la manera correcta.

Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Fifth Edition, Project
Management Institute, Inc., 20013, Gráfico 3-1, Página 50.

PMI es una marca registrada del Project Management Institute, Inc..

34
Como se observa en la figura, los grupos de proceso en el ciclo de vida de la gestión, coinciden, como
debe ser, con la responsabilidad del PM; se les llama grupos de proceso, debido a que en cada uno
de ellos hay al menos dos procesos distintos, mediante los cuales, el o la PM puede llevar a cabo
con éxito su rol, y puede llevar a que el proyecto transite o haga transición de una etapa a la otra de
manera correcta.

En Scrum® por ejemplo, los procesos, también llamadas etapas son también cinco (5), y los mismos
contemplan, los procesos de Iniciación, para definir el producto, realizar una planificación general
del proyecto y definir la estructura general de la etapa de desarrollo, los siguientes tres procesos,
ocurren precisamente durante la etapa de desarrollo del proyecto de manera iterativa, la cantidad
de veces que se definió en la etapa de Iniciación citada, y se conocen como procesos de Planificar y
Estimar, durante los cuales el equipo Scrum® planifica y estima el esfuerzo de la iteración que es
conocida como Sprint; el siguiente proceso, se conoce como Implementar, y como su nombre lo
indica, es precisamente donde, dentro de la iteración se implementa el trabajo; posterior a este, se
realiza el proceso/etapa conocid(a) como Revisión y Retrospectiva, en el cual el equipo demuestra
los resultados y posteriormente se revisa lo ocurrido. Por último, una vez ocurridas y completadas
todas las iteraciones dentro de la etapa de desarrollo, se procede con la etapa/proceso de
Lanzamiento, en el cual, el producto se “lanza” o entrega al cliente y se transiciona a operaciones el
mismo.

35
Resulta especialmente importante, recalcar que lo que desarrollaremos de aquí en adelante, NO es
una metodología, la metodología, como hemos indicado en reiteradas ocasiones, es propia de cada
organización, y en la misma, se utilizan de manera discriminada las herramientas y procesos que la
organización considere pertinente; sin embargo, con el objetivo de generar claridad, de aquí en
adelante mencionaremos y desarrollaremos, las herramientas y procesos, que consideramos
primordiales, para una adecuada gestión de proyectos, y en el desarrollo de dichos procesos,
citaremos o haremos referencia a herramientas o procesos propuestos por alguna de las guías o
estándares citados, utilizando eso sí, el PMBOK® Guide y sus procesos como base fundamental.

Como bien indicáramos en capítulos anteriores, el PM es responsable último del correcto fluir del
proyecto, de una etapa a otra del mismo, y una adecuada gestión de proyectos, es la principal
herramienta para lograrlo; así, nos permitimos resumir, las herramientas y procesos que
consideramos indispensables como MÍNIMO para poder incluso decir que estamos gestionando un
proyecto.

36
De la figura anterior podemos extraer cierta información, y también concluir un aspecto
fundamental dentro de la gestión de proyectos; primero, que la información es PODER, ya que el
flujo correcto y constante de la misma le permitirá al PM gestionar de manera más sutil o menos
complicada el proyecto como un todo, y segundo, que existen una serie de aspectos básicos que
TODO PM debe no solo comprender, sino también manejar muy bien para poder llevar a cabo el
proyecto. Estos aspectos básicos son:

37
Etapa de Inicio

Desde la perspectiva de gestión, los siguientes dos procesos (Procesos de Inicio), son indispensables
en la etapa de inicio del proyecto, pero también pueden ocurrir al inicio de cada etapa, es decir,
podría desarrollarlos o actualizarlos conforme avanza el proyecto de una etapa a otra.

1. Un Charter (Acta Constitutiva) para Garantizar que se comprende:

a. ¿Qué debo entregar con el Proyecto? (Producto)
b. ¿Qué trabajo debo hacer para crear y entregar el Producto? (Proyecto)
c. ¿Para cuándo debo entregar el producto?
d. ¿Con qué presupuesto/recursos contamos para desarrollar el trabajo?

*Nótese que para realizar un Charter, NO necesito ni procedimientos ni procesos nuevos. La excusa
de que “en mi organización eso no se puede hacer”, resulta INVALIDA. Ya sea que pertenezco a una
organización “proyectizada” donde existe un proceso y una plantilla para ello, o una organización
funcional, donde NO existe nada similar, tomarme 10 minutos de mi tiempo para responder esas
preguntas básicas no está restringido por nada, y puede ahorrarme muchísimos dolores de cabeza
en el futuro.

*Este charter puede complementarse con otros aspectos importantes como supuestos y
restricciones, que discutiremos más adelante

2. Un Registro de Interesados para también garantizar que entendemos a quién

puede afectar el producto del proyecto, y el desarrollo del mismo

La correcta ejecución de estos dos procesos obligará a solicitar y validar toda la información
generada para el proyecto, durante los procesos de factibilidades, estudios de mercado, caso de
negocio, proceso comercial y otros que se presentan previo a que la iniciativa se convierta en
proyecto.

Etapa de Planificación

Desde la perspectiva de gestión, esta resulta ser la etapa MÁS Crítica e IMPORTANTE para el PM, ya
que en ella es en la que se valida que lo que refleja el Charter, sea realizable, es decir, para lo que
me están solicitando entregar, los recursos y el tiempo asignados son suficientes.

Hay muchos procesos asociados a la planificación, de hecho, es el grupo de procesos que más
procesos contiene, sin embargo, esto debe entenderse como lo que es, un proceso que es iterativo,
y que, por lo tanto, puede darse de una manera integral en la etapa de planificación, o de manera
iterativa, iniciando en la etapa de planificación, y complementándose en las etapas de desarrollo,

38
esto según el ciclo de vida del proyecto (cantidad de sub-etapas en la etapa de Desarrollo), o la
metodología de gestión que se utilice para la gestión.

Así, durante la etapa de planificación, el objetivo principal debe ser la creación de un Plan de gestión
de Proyecto, el cual le permita al PM tener claridad de lo que debe entregar, así como la estrategia
para realizarlo, dirigirlo y controlarlo, y que todo, sea validado y aprobado por el cliente, junto con
la presentación o realización del “Lanzamiento del Proyecto”, lo que se conoce como Kick-Off en
inglés.

Nótese que el Kick-off o lanzamiento, ocurre SOLO una vez que la planificación se ha concluido, al
menos en su primera iteración, y que el Plan de Gestión ha sido aprobado y validado por mi cliente.

Si estoy utilizando la metodología Scrum®, me encuentro finalizando la etapa de Inicio (Iniciación),

y tengo un Backlog del Producto, un Plan de Liberación y un tamaño de Sprint definido, con esto
hago el Kick-off/Lanzamiento.

Si en cambio estoy utilizando PRINCE2®, estoy al final de la etapa de Inicio, tengo todos mis Toll-
gates y Entregas definidas.

Indiferentemente del método que se utilice, los siguientes son los procesos son los básicos a la hora
de planificar un proyecto: (*Nótese que todos estos procesos se desarrollarán con detalle en
capítulos posteriores)

1. Recopilar Requisitos: este es un proceso que no debe confundirse con el proceso conocido
como Levantar Requerimientos, ya que en el segundo, lo que se hace es comenzar de cero
con el cliente a levantar los requerimientos para definir el producto, este proceso, ocurre
en las etapas previas cuando la iniciativa aún no es un proyecto, mientras, que el proceso al
que nos referimos, es uno en el que lo que se hace es, a partir de la información ya existente
para el proyecto, entiéndase SOW (Statement of Works – Declaración de Trabajos),
Contrato-Acuerdo, Ofertas, entre otros, determinar los requisitos o requerimientos para el
producto (especificaciones) y para el proyecto (aspectos que afecten la ejecución del
trabajo, entiéndanse políticas, metodologías, regulaciones, etc). Este proceso genera lo que
se conoce como una Matriz de Trazabilidad de Requerimientos, y la construcción de la
misma, es reflejo de una adecuada lectura y comprensión de TODO lo que circunscribe el
proyecto en cuestión.
2. Definir el Alcance del Proyecto: Este es un proceso crítico para el PM, ya que en él se
determina de manera
3. Creación de la Estructura de Desglose de Trabajo (EDT): La EDT es la herramienta por
excelencia del PM, esta es la base para el proceso de planificación, dirección y control, ya
que en ella se encuentra reflejado todo el trabajo que el proyecto debe realizar para
desarrollar y entregar el producto.

39
4. Definición de recursos necesarios para la ejecución del trabajo: Para cada paquete de
trabajo de la EDT, debemos entonces determinar los roles y responsabilidades
correspondientes, con lo que tendremos un Organigrama y una Matriz de
Responsabilidades (RAM).
5. Identificación y Análisis de Riesgos: Una vez que el trabajo del Proyecto ha sido definido, y
que tenemos claridad de TODO lo que debo realizar para crear el producto, podemos
entonces identificar lo que puede salir mal en la ejecución de dicho trabajo o esfuerzo, en
este proceso, los riesgos encontrados se analizan, se priorizan, y se definen estrategias de
gestión para los mismos, lo que puede llevar a procesos de Calidad, Subcontrataciones o la
adquisición de seguros, por ejemplo. El producto de este proceso es lo que se conoce como
la Matriz de Riesgos.
6. Definición de los Criterios de Aceptación y procesos de Calidad: Para cada uno de los
entregables definidos en los puntos 2 y 3, debemos entonces definir cuáles son los criterios
mínimos para que estos sean aceptados por nuestro cliente; así mismo, según el tipo de
trabajo que debemos realizar, debemos identificar que estándares aplican para el mismo, y
por último, para aquellos riesgos que sea necesario mitigar o disminuir su probabilidad de
ocurrencia, debemos entonces definir pruebas, inspección o auditorías como herramientas
y procesos necesarios. De este proceso obtenemos Listas de Verificación, así como
actualizaciones a la EDT.
7. Creación de un Cronograma de trabajo: Una vez que se tienen TODOS los insumos
necesarios para la creación del Cronograma, podemos entonces proceder a crearlo; nótese
que el Cronograma NO es el plan del Proyecto, y que para poder desarrollarlo,
NECESITAMOS TODA LA INFORMACIÓN previa, sea que tengamos un proceso formal y
herramientas de documentación, para hacer el cronograma SIEMPRE llevamos a cabo los
pasos 1-6, solo que al hacerlo de manera informal, podemos omitir aspectos importantes,
de hecho más del 80% de los PMs NO hacen esto en el orden adecuado. Sin Riesgos, no
tengo Calidad definida, sin esto no tengo pruebas que requieren tiempo y dinero para poder
desarrollarse, por lo tanto, impactan mi cronograma. El producto de este proceso debe ser
mi cronograma con la Ruta Crítica, la cual debe validarse versus la restricción de tiempo que
nos ha sido dada.
8. Creación de un presupuesto: Para el tiempo de desarrollo del proyecto, con los recursos
asignados, según su asignación, podremos entonces determinar el presupuesto necesario
para el desarrollo del proyecto, el cual debe también validarse versus la restricción de
presupuesto que nos fue dada para desarrollar el proyecto.
9. Determinación de productos o servicios que deben obtenerse de terceros
(planificar las adquisiciones): A partir de la determinación de recursos, así como del
análisis de riesgos, podemos y debemos determinar que recursos necesitamos que
sean provistos por terceros fuera del equipo de proyecto.

40
 10. Creación de Plan de Comunicación: A estas alturas de la planificación, ya tendremos
claridad de todo lo que debemos entregar, los riesgos asociados, los procesos necesarios
para la aceptación, los recursos necesarios, y la validación de tiempos y costos versus las
restricciones, por lo que podemos entonces definir como los recursos y los otros
interesados, deberán comunicarse durante el proyecto, para garantizar el flujo de
información y la correcta ejecución del proyecto. El primero producto de comunicación
deben ser la comunicación del Plan de Gestión por medio del Lanzamiento/Kick-off.

Etapa de Desarrollo

Esta es la etapa que usualmente le da nombre al proyecto, por lo tanto, resulta ser a la que, por
ende, se le da más importancia, debido principalmente a que es en la que se produce o crea el
producto, es la que le interesa a nuestro cliente, y es en la que el equipo desarrolla todo el trabajo
definido en la planificación.

Aquí es donde podemos ver los distintos tipos de “ciclos de vida” por industria, usualmente dichos
ciclos se refieren a la etapa de desarrollo como tal.

Desde la perspectiva de gestión, en esta etapa, el trabajo del PM se circunscribe a Dirigir y Controlar
el trabajo que el equipo desarrolla, y es en la que existe una mayor variedad de herramientas para
llevar a cabo la gestión, y donde más diferencias se ven entre un marco y otro, o entre una
metodología y otra.

Si el tipo de proyecto, lo amerita y permite, podemos entonces utilizar Scrum, con sus herramientas
para Definir, Controlar y Revisar cada una de las iteraciones (Sprints) que se definieron en el Plan.

Como bien indicamos nuestro objetivo en esta etapa es la correcta producción de los entregables
(Producto), así como la aceptación del mismo por parte de nuestro cliente; para ello, resulta
indispensable que el equipo funcione como tal, algo que es responsabilidad UNICA del PM,
indistintamente del tipo de proyecto y de la organización en la que se desarrolle el proyecto. Un
equipo es un equipo, y solo dirigiéndolo correctamente podrán obtenerse resultados satisfactorios.

Así, podemos definir los siguientes procesos como INDISPENSABLES para una adecuada Gestión:

41
Dirección:

1. Dirigir el trabajo: Este es el proceso puntual de dirigir a el o los equipos involucrados en el

proyecto, responsables de trabajos de gestión en proyectos con alta cantidad de personas,
trabajos de entrega y trabajos de apoyo. Recordemos que el PM NO es responsable de ejecutar
dichos trabajos, con excepción de los trabajos de gestión cuando no cuente con un equipo de
gestión; más sin embargo es responsable último (accountable) de la correcta ejecución de dichos
trabajos para producir los entregables del proyecto.
2. Adquirir y Formar el Equipo de Proyecto: si tengo la potestad para seleccionar el equipo,
buscar según los perfiles definidos, y seleccionar según los criterios técnicos y valores del
equipo. Si me los “dan”, invertir en alinear los valores y establecer la cultura de equipo.
Deben de tenerse en cuenta los factores de temporalidad y criticidad de los recursos para
determinar el método para traerlos al proyecto.
3. Gestionar los Conflictos dentro del Equipo: Conforme el proyecto avance, deben
presentarse conflictos y mi trabajo como PM implica eliminar las trabas para que el equipo
funcione de la mejor manera, como lo hace el Scrum Master en Scrum®.
4. Asegurar que se den las adquisiciones: En la mayoría de los casos, las adquisiciones NO las
realiza el PM, quizás puede cotizar y pre-negociar con posibles proveedores, pero al final
será compras-adquisiciones quien realice la compra, y en caso de que deba existir un
contrato, legal quien realice el mismo, sin embargo, la responsabilidad última de que estas
cosas ocurran para que el proyecto pueda tener los servicios o productos externos, es del
PM.
5. Asegurar que se sigan los procesos establecidos: es también responsabilidad del PM, velar
por la correcta ejecución de los procesos, ya sea los productivos o los administrativos
relacionados al proyecto.
6. Comunicar: Se dice que 90% del tiempo de un PM es para comunicarse, de ahí, que sea
crítico que el Plan de Comunicación establecido, se ejecute al pie de la letra, y sea
complementado con actividades de comunicación informal.

Control:

1. Controlar los cambios: Esto se conoce como el control integrado de los cambios al proyecto,
cambios a cualquiera de los aspectos que fueron planificados, deben ser Controlados, en
este proceso recae un alto porcentaje de los fracasos en proyectos.
2. Controlar el avance del Proyecto: Específicamente en lo que respecta a la Ruta Crítica y el
presupuesto (Líneas base) que fueron validados versus las restricciones, un rendimiento
adecuado del proyecto durante la ejecución, aumenta las probabilidades de éxito. Debe
tenerse en cuenta que los riesgos definidos son insumo para dichas líneas base, y deben de
controlarse aquí también.

42
 3. Controlar la Calidad del Producto: Velar por el cumplimiento de los entregables versus los
criterios de aceptación definidos es CRUCIAL para el éxito del proyecto.
4. Lograr la aceptación de los entregables: De poco servirá producir los entregables, si el
cliente NO los acepta, solo logrando esto último, podremos cerrar el proyecto.
5. Administrar las relaciones con proveedores: si existen adquisiciones en el proyecto, el PM
es el responsable de que las relaciones con los proveedores sean las mejores.

Para llevar a cabo los procesos citados arriba, podemos utilizar un sinfín de herramientas, plantillas
y procesos, según el marco de referencia que se utilice y según la metodología que se tenga, sin
embargo, lo que NO puede ocurrir, es omitir alguno de estos procesos como tal.

43
Etapa de Cierre

Como bien lo hemos indicado anteriormente, a esta etapa podemos llegar si y solo si, el último
entregable ha sido entregado y validado por nuestro cliente, es decir, ha sido aceptado. Desde la
perspectiva de gestión, el trabajo amerita los procesos necesarios para cerrar las adquisiciones,
liberar los recursos, documentar todo lo que sea necesario y cerrar el proyecto o la fase como tal.
Así, existen dos procesos fundamentales:

1. Cerrar adquisiciones: En este proceso el PM debe asegurarse de que no quede ningún

contrato, orden de compra, o vínculo contractual con algún proveedor del proyecto, abierto
o no resuelto. Una vez aceptados los entregables o servicios que debieron ser provistos por
dichos proveedores, las relaciones deben ser cerradas con cada uno.
2. Cerrar fase o Proyecto: esto es un proceso que realmente tiene varios pasos, ya que no solo
debemos cerrar todo el trabajo, sino que debemos documentar lecciones aprendidas,
liberar recursos, hacer el cierre administrativo y comunicar a todos los interesados que el
proyecto ha concluido.

Como podemos observar, la gestión del proyecto es distinto al ciclo de vida, está directamente
relacionada con el mismo, pero según el tipo de marco que se utilice y el método de gestión que se
escoja, dicha gestión puede variar, sin embargo, el PM lo que debe tener claro, es que su
responsabilidad, sigue siendo la misma, es decir, debe de iniciar, planificar, dirigir, controlar y cerrar
el proyecto.

El trabajo indicado anteriormente, nos permite no solo comprender el rol del PM, y sus
responsabilidades, sino que también nos permite justificar la necesidad de la existencia de alguien
(persona u organización), responsable del tipo de trabajo administrativo que mencionamos en el
capítulo 3, y que hemos explicado brevemente en los párrafos anteriores de este capítulo.

Resulta también muy importante indicar que según la composición de personal necesaria para el
proyecto, así será la composición y necesidades de recursos humanos (personal) para la realización
del trabajo de tipo administrativo del cual versa este libro; para equipos de proyecto con más de 10
personas, se comienza a hacer necesaria, la creación de lo que se conoce como un equipo de gestión
(administración), es decir, se vuelve indispensable que el PM tenga más “brazos” para poder realizar
el trabajo administrativo, esto debido a que la coordinación del equipo, requerirá sin duda mayor
tiempo, por lo que se requerirá personal para la ejecución de alguno(s) de los procesos de gestión
que hemos citado con anterioridad.

44
Áreas de Conocimiento – Aspectos - Temas de Gestión

Indiferentemente del tipo de proyecto que deba el PM gestionar, existen una serie de “conceptos,
términos y actividades que conforman un ámbito profesional, un ámbito de la administración del
proyecto o un área de especialización” (PMI, 2017:XX), con funcionalidades y responsabilidades
específicas, las cuales deben gestionarse a lo largo de todo el ciclo de vida del proyecto. Se conocen
dentro del Marco del PMI® como áreas de conocimiento, como aspectos dentro del marco de
SCRUM® y como Temas de gestión dentro del Marco de PRINCE2®, y usualmente se alinean con las
áreas de negocio dentro de las organizaciones grandes.

Así tenemos por ejemplo para SCRUM®:

• Organización
• Justificación del Negocio
• Calidad
• Cambio
• Riesgo

En PRINCE2®:

• Caso de Negocio
• Organización
• Calidad
• Planes
• Riesgo
• Cambio
• Progreso

Dentro del marco del PMBOK® Guide del PMI®:

• Integración
• Alcance
• Cronograma
• Costo
• Calidad
• Recursos
• Comunicaciones
• Riesgos

PMI y PMBOK son marcas registradas del Project Management Institute, Inc.

45
 • Adquisiciones
• Interesados

Estos, aspectos, temas y áreas de conocimientos están presentes en absolutamente TODO proyecto,
y es responsabilidad el PM o del equipo de gestión la gestión de las mismas, aunque es claro, que
según el tipo de organización en la que se encuentre el PM, y el tipo de proyectos que gestione,
algunas de estas queden fuera de su injerencia.

Y dentro del IPMA® ICB®:

• Diseño
• Metas, objetivos y beneficios
• Alcance
• Tiempo
• Organización e información
• Calidad
• Finanzas
• Recursos
• Adquisiciones
• Planificación y Control
• Riesgo y oportunidad
• Interesados
• Cambio y transformación
• Selección y balance

Estos, aspectos, temas y áreas de conocimientos están presentes en absolutamente TODO proyecto, y
es responsabilidad el PM o del equipo de gestión la gestión de las mismas, aunque es claro, que según el
tipo de organización en la que se encuentre el PM, y el tipo de proyectos que gestione, algunas de estas
queden fuera de su injerencia.

46
Las etapas o actividades previas al proyecto

****figura procesos previos al proyecto**** gestión del portafolio

Preproyeto FALTA IMAGEN CORREGIDA

Como hemos citado en el capítulo uno, la organización que necesita resolver el problema u oportunidad
es la llamada a realizar las actividades y procesos necesarios para llevar traducir su necesidad en un
proyecto que permita entregar el producto que se espera resuelva dicho problema.

Si bien es cierto, que lo que ocurra antes de que el proyecto sea reconocido formal y oficialmente
por la organización como tal, no es responsabilidad del PM, lo que si resulta primordial para el PM,
es el tener una comprensión profunda de lo que ocurrió previo a su llegada al proyecto, todo lo que
la organización ejecutora, y el cliente han realizado para llegar al punto de iniciar el mismo, los
beneficios que se esperan que el producto del proyecto genere, así como la justificación de negocio
que dio o da origen al proyecto como tal, y la definición del producto que debe entregarse.

Por otro lado, entendemos y estamos conscientes, de que en muchas organizaciones, los PMs, o
participan en estas etapas o actividades previas, o incluso en ocasiones, son responsables de la
ejecución de las mismas, algo que a todas luces, en caso de ocurrir, no puede ser más que
beneficioso para el proyecto en cuestión, sin embargo cuando no resulta ser, es cuando ni el mismo
PM entiende, que su rol en esas etapas, NO es el de PM, sino el de un consultor/asesor que se
encuentra apoyando a la organización en procesos de validación y aprobación de iniciativas,
procesos propios de la gestión del portafolio que veremos más adelante. Es un consultor/asesor por
el simple hecho de que la iniciativa aún NO es un proyecto, y, por lo tanto, NO PUEDE tener un PM
asignado.

Ahora bien, algo que un PM, tampoco puede aducir, es desconocimiento de lo que ocurre con una
iniciativa, para que la misma se convierta en proyecto, pues como bien vimos en la sección anterior,
el aspecto o tema de la Justificación de negocio, resulta crítica para la existencia del proyecto, ya
que en el momento es que esta justificación deje de ser válida, el proyecto debe ser “matado”, o
terminado; aunado a esto, si bien es cierto que el proyecto como tal suele NO generar beneficios
para el cliente (si lo hace para la organización ejecutora del proyecto), y que el producto SIEMPRE
es el que genera los mismos, y que la gestión de beneficios, realmente NO es responsabilidad del
PM, debemos también indicar, que SI es responsabilidad el PM, el comprender dichos beneficios
esperados, pues estos están relacionados directamente con la Justificación de Negocio citada
(relación Beneficio (Producto)/ Costo (Proyecto)).

También, el PM debe conocer y comprender por qué se decidió realizar el proyecto, por qué resulta
ser factible, tanto económica, como operacional, técnica y socialmente para la organización de su
cliente, y para la suya también.

47
Y por último, como bien hemos indicado anteriormente, el PM, jamás puede aducir
desconocimiento del producto que será responsable de entregar al cliente.

Debido precisamente, a todos esos aspectos que resultan críticos, no solo para el proyecto, sino
incluso más para la gestión del mismo, es que nos permitimos reflejar de manera general, en esta
sección, los procesos que deberían ocurrir previo a que el proyecto inicie, y que permiten convertir
una iniciativa como tal en un proyecto.

Los Tres Insumos Básicos:

Para poder comprender el entorno del proyecto, así como lo realizado antes por la organización
ejecutora y la del cliente, el PM NECESITA recibir la información que refleje y evidencie todo lo que hemos
citado con anterioridad, así que necesita información que le permita comprender la justificación del
proyecto y su alineamiento con la estrategia de la organización o la relevancia estratégica del mismo,
esto puede encontrarlo en el Caso de Negocio; dicho caso de negocio y la relación Beneficio (del
Producto) / Costo (del Proyecto) le permitirá “mantener” la justificación del proyecto, todo en cuanto
que los costos del proyecto se mantengan siempre por debajo del costo estimado en el caso de negocio,
para que la relacion Beneficio / Costo se mantenga o mejrore, más nunca sea igual a uno o menor. Otro
documento de evidencia primordial, resulta ser el conocido como SOW por sus siglas en inglés
(Statement of Works), que no es otra cosa que las Especificaciones Técnicas del Producto y la descripción
de cómo este satisface la necesidad u oportunidad o resuelve el problema por el cual se justifica hacer
el proyecto. Por último, el PM necesita contar con el Acuerdo o Contrato según el tipo de proyecto, que
muestra lo acordado entre el Cliente y el Patrocinador y que determina las restricciones básicas de
Tiempo y Costo para el proyecto.

Debido precisamente, a todos esos aspectos que resultan críticos, no solo para el proyecto, sino incluso
más para la gestión del mismo, es que nos permitimos reflejar de manera general, en esta sección, los
procesos que deberían ocurrir previo a que el proyecto inicie, y que permiten convertir una iniciativa
como tal en un proyecto.

El Pre-Proyecto

De manera general podemos entonces decir, que antes de que el proyecto sea considerado un proyecto,
el mismo es más bien una INICIATIVA, una iniciativa que nace a partir de una Necesidad u Oportunidad
de Negocio que tiene mi cliente. Precisamente debido a que la necesidad es de mi cliente, en esta etapa
del ciclo de vida de la iniciativa, es el (cliente) quien es responsable de llevar a cabo estas actividades, y
en caso de contar la organización con madurez en el tema de la Gestión Empresarial de Proyectos (EPPM
(Enterprise Project, Program and Portfolio Management)), este proceso es responsabilidad del Gestor
o administrador del portafolio, como citaremos en breve y con detalle en el capítulo correspondiente.xm

48
Ciclo de Vida de la Iniciativa

Como puede observarse en la figura xxx, toda iniciativa debería pasar por el flujo de análisis y validación,
y debe competir con las otras iniciativas de la organización por recursos, según su criticidad.

El ciclo de vida de las iniciativas es parte de la gestión del portafolio, que desarrollamos más adelante; a
pesar de que la misma es “un proceso continuo, a diferencia de los procesos de gestión de programas y
proyectos que tienen fechas de inicio y fin programadas, ciertas actividades pueden tener tiempos
definidos” (PMI, 2013), dentro de estas actividades podemos ubicar el ciclo de vida de las iniciativas.

Debemos recalcar que este ciclo NO ES RESPONSABILIDAD del PM, precisamente porque son iniciativas
y no proyectos lo que se gestiona en este momento.

49
FALTA CORREGIR IMAGEN

Como puede observarse en la figura previo al inicio de cualquier proyecto o programa, las iniciativas que
surgen o se proponen siguen los procesos circunscritos en el proceso llamado de alineación, el cual

50
podemos considerar como el ciclo de vida de las iniciativas. Una iniciativa autorizada (proceso 1.6) se
convierte en proyecto, por lo que muere o se cierra el ciclo de vida de la iniciativa y nace o inicia el ciclo
de vida del proyecto o programa.

Así, las iniciativas se:

1. Identifican
2. Evalúan
3. Seleccionan
4. Priorizan
5. Se utilizan para balancear el portafolio
6. Autorizan

Un aspecto clave a considerar, es que las competencias requeridas para la administración o gestión de
un portafolio, como hemos mencionado con anteriorirdad, son bastante distintas que las requeridas
para la gestión o adminitración de proyectos, algo que ya hemos mencionado antes, de ahí el comentario
anterior, de que NO es responsabilidad de ningún PM la administración de un portafolio, más aún cuando
podemos asegurar que mas del 90% de los PMs en el mundo no tienen ni las competencias, ni los
conocimientos para realizar dicha labor, y mucho menos la autoridad para hacerlo.

El Rol de las Oficinas de Proyectos

De manera errónea en el mundo del PPPM, se ha interpretado y asignado la responsabilidad de gestión

de Oficinas de Proyectos a algunos buenos PMs, quizás por que el nombre de la oficina incluye la palabra
Proyectos, quizás por el mismo aspecto “Egótico” de pretender que los proyectos son el eje de toda
organización, cuando en realidad TODOS sabemos que la producción lo es. No se malinterprete este
último comentario, no estoy demeritando ni quitando importancia a la dirección de proyectos, este es
un libro de ello, y yo, el autor soy el más creyente en su potencial y capacidad para transformar el mundo
y las organizaciones, sin embargo, resulta crítico decir las cosas como son y sentar bases para la discusión.

Las Oficinas de Proyectos (PMOs), cuyos nombres han sufrido “n” cantidad de mutaciones o
transformaciones, según las mismas han ido “escalando” dentro de las estructuras jerárquicas de las
organizaciones, tambien han sufrido un sinfín de transformaciones en su propia definición. Hoy en día
ya existen métodos para la creación y evaluación de PMOs, e incluso existen Certificaciones para
practicantes dentro de este tipo de organizaciones, las cuales definen claramente que los perfiles de las
personas que ejecutarán las actividades de la PMO, varían según las responsabilidades que les han sido
definidas.

Aquí llegamos a un punto importantísimo, el cual ha sido alcanzado con la madurez en el desarrollo de
PMOs a nivel global, y dicho punto, es precisamente el aspecto de la alineación de las funciones de la
PMO con las expectativas de beneficios de los stakeholders de la misma, los cuales son muy distintos por
definición a los stakeholders de los proyectos que son parte de un portafolio. Organizaciones como el

51
PMO Global Alliance ha hecho esfuerzos interesantes en este tema, los cuales han permitido terminar
de aclarar la segregación de roles y la diferenciación entre un PM y un miembro administrativo o directivo
de una PMO.

52
 Capítulo 5

Comprendiendo los procesos de Gestión básicos

o fundamentales
En el capítulo anterior mencionamos los procesos de gestión fundamentales pare el desarrollo de lo que
consideramos una correcta gestión de proyectos. En este capítulo, desarrollaremos con mayor
profundidad cada uno de dichos procesos, citaremos algunas herramientas, e incluso veremos como el
mal llamado “Agilismo”, o lo que preferimos nombrar como la aplicación de la filosofía ágil puede
impactar los procesos en cuestión.

Etapa de Inicio

En esta etapa hemos indicado dos procesos clave que permitirán el PM tener claridad sobre el proyecto
en el cuál ha sido involucrado, el producto que se espera, los recursos con los que se cuenta, la
temporalidad definida para la entrega del producto, así como los distintos interesados en el proyecto en
cuestión.

Aquí debe tenerse claridad y certeza, de que sin importar la filosofía o enfoque que se utilice, los dos
procesos citados (Desarrollo del Charter del Proyecto y la Identificación y Análisis de Interesados), DEBEN
realizarse sin excepción, si es que el PM pretende poder claridad sobre el proyecto al que ha sido
asignado.

53
Para poder crear un charter y responder las preguntas ¿qué debemos entregar?, ¿qué debemos hacer
para poder entregar?, ¿cuándo debemos entregar?, ¿cuántos recursos tenemos disponibles? y ¿quién
puede apoyaros u oponerse al proyecto?, resulta imprescendible contar con las evidencias/documentos
que debieron crearse en las etapas previas a que el proyecto fuera una realidad, y los que debieron ser
creados por mi cliente, sea interno o externo a mi organización como ejecutora del proyecto.

Estos documentos incluyen al menos, el Caso de Negocio, del cual claramente podremos obtener el
beneficio que se espera que el producto del proyecto entregue, así como el costo inicialmente esperado
o estimado para el proyecto; ambos datos, permitieron a la organización de mi cliente justificar la
ejecución del proyecto para crear y entregar el producto, debido a que los beneficios del mismo son
mayores a los costos asociados al desarrollo del proyecto como tal.

Un segundo documento crítico para la comprensión del entorno, y especialmente importante para
responder la pregunta ¿qué debemos entregar?, es el que se conoce como la Declaración de Trabajos o
Statement of Works (SOW), la cual no es más que un documento que describe con el mayor detalle
posible las especficaciones técnicas del producto que el proyecto espera o debe entregar; un aspecto
importante a considerar es que existen muchas ocasiones en las que nuestro cliente NO TIENE claridad
sobre el tipo de producto que necesita, o no tiene los conocimientos para determinar que
especificaciones debe tener el mismo para resolver su problema o necesidad. Si se encuentra en este
tipo de situación, el PM tendrá la responsibilidad de tomar una decisión, y esta será la de volver con su
cliente y patrocinador para establecer la mejor manera para determinar las especificaciones del producto
y crear el SOW; esta decisión, se verá afectada o influenciada por el entorno en que se esté desarrollando
el proyecto, las necesidad y conocimiento del cliente sobre el potencial producto, e incluso la definición
de los beneficios esperados para el producto en cuestión. Es precisamente por situaciones como estas,
debidas a los entornos tan volátiles y acelerados en los que se desenvuelven los negocios de hoy en día,
que el “agilismo” ha cobrado tanta fuerza en tiempos recientes; la necesidad de tener la capacidad de
responder de manera flexible ante los cambios en el entorno de una manera expedita, ha potenciado
enfoques “distintos”, supuestamente menos rígidos para afrontar la incertidumbre. De ahí, que en
entornos o situaciones, en las que el SOW no esté claramente definido, o cuando el proyecto se
desarrolle en un entorno altamente incierto, se recomiende utilizar las prácticas fundamentadas en los
principios ágiles que pueden encontrarse en el “Manifiesto Ágil”, tales como Scrum y Kanban para la
gestión de proyectos, con el objetivo principalmente de reducir el riesgo y la incertidumbre utilizando
iteraciones cortas para entregas incrementales del producto que no está claramente definido.

Así, la decisión del PM ante la ausencia de un SOW claramente definido esta circunscrita a dos opciones
principalmente:

1. Detener el proyecto, indicar claramente que sin una definición del producto resulta muy
riesgoso realizar estimaciones de esfuerzo y comprometer tiempos y costos del mismo
(proyecto); y solicitar al cliente que defina de manera explicita el SOW como tal, e incluso ofrecer
ayudar a crearlo, entendiendo eso sí, que se estará quitando el “sombrero” de PM para actuar
como Consultor o analista de negocio pues el proyecto esta “detenido” y estamos “volviendo”
a las etapas previas al mismo.

54
 2. Incluir el desarrollo o creación del SOW dentro del alcance (esfuerzo) del proyecto, pudiendo
para esto utilizar varias estrategias o filosofías:
a. Seguir el modelo “tradicional” de etapas secuenciales e incluir una etapa de “Definición
o Conceptualización del producto”, y en la misma desarrollar el levantamiento de
requerimientos y creación del SOW (trabajo del analista de negocio)
b. Seguir la filosofía del agilismo y “descomponer” la etapa de desarrollo del proyecto en
iteraciones que permitan ir “definiendo” el producto mediante la entrega de
incrementos del mismo para validación y aprobación.

Indiferentemente del tipo de decisión que el PM tome, dado que ambas son válidas y dependientes del
entorno en que se encuentre, lo crítico resulta ser la determinación del SOW y por ende de las
especificaciones del producto que debemos entregar.

El tercer documento o insumo fundamental para la etapa de inicio, es el ACUERDO o CONTRATO,

principalmente debido a que en el mismo podemos encontrar que es exactamente a que se
comprometieron mi Sponsor (el que fondea el proyecto, es decir el que provee recursos para llevarlo a
cabo), y mi cliente (el que recibe y paga por el producto); en capitulos anteriores indicamos que SIN
CONTRATO NO HAY PROYECTO, por lo que indiferentemente del entorno, método, filosofía o
mecanismo que se utilice para gestionar los proyectos en mi organización, esta premisa no puede ni debe
obviarse.

Puede que existan otros insumos para el proyecto, por ejemplo, estándares de ejecución para el trabajo
de entrega, regulaciones del país en el que se desarrolle el proyecto, procedimientos de la organización
ejecutora o del cliente, así como alguna metodología para el desarrollo y gestión de proyectos que deban
tomarse en cuenta y seguirse, sin embargo, estos varían de proyecto a proyecto, y de organización a
organización, precisamente dando pie al concepto de unicidad de los proyectos (todo proyecto es único
y produce un producto único).

55
Todo lo citado anteriormente servirá al PM para poder realizar el proceso de Identificar y Analizar los
Stakeholders (interesados) del proyecto, es decir, todas aquellas partes, organizaciones o personas que
puedan verse afectadas positiva o negativamente por el desarrollo del proyecto y/o por la entrega del
producto.

56
Este proceso, es quizás uno de los más críticos para el proyecto, ya que permite al PM entender el
entorno en el cual se desarrollará el proyecto, lo que le permitirá a su vez, entender los posibles riesgos
asociados con la oposición al mismo, la resistencia al cambio, la asignación de recursos, la prioridad
versus otros proyectos del portafolio, la comprensión de precursores versus opositores, y solo así, contar
con un insumo primordial para definir estrategias políticas para el proyecto.

Este ejercicio político, de poco agrado para muchos PMs, es FUNDAMENTAL para el éxito del proyecto;
lograr el compromiso de todos los stakeholders es trabajo de todos los días, y dado que los intereses y
el poder de los mismos pueden cambiar durante las distintas etapas del proyecto, el proceso de
identificación y análisis inicia en esta etapa de inicio, sin embargo, se debe revisar y quizás ejecutar previo
al inicio de cada etapa posterior del proyecto como tal.

Como hemos indicado anteriormente, el entorno del proyecto, las regulaciones y procedimientos del
mismo, podrían requerir la ejecución de algunos otros procesos, más estos dos, son responsabilidad de
todo PM y DEBEN ejecutarse en cualquier tipo de proyecto.

Etapa de Planificación

Cómo bien hemos mencionado ya en varias ocasiones, esta etapa es la MÁS CRITICA y por ende debiera
ser la MÁS IMPORTANTE para todo PM, la correcta ejecución de la planifiación del proyecto, es lo que
permitirá una adecuada dirección, un correcto control y un efectivo cierre del proyecto posteriormente.

57
En esta etapa es cuando más necesita el PM las habilidad de análisis crítico e integración para poder
crear un plan conciso que permita dirigir, controlar y cerrar el proyecto una vez entregado el producto a
satisfacción del cliente.

Resulta importante aclarar en este momento, que de manera erronea, muchas de las personas que
defienden a capa y espada el agilismo, insisten en que en los métodos ágiles NO SE PLANIFICA, algo que
a todas luces es bastante alejado de la realidad, ya que lo que realmente ocurre cuando sigo métodos
que siguen la filosofía ágil, es descomponer mi planificación en iteraciones, es decir, la cantidad de
planificación presente, indiferentemente del método o enfoque/filosofía que se utilice para gestionar el
proyecto, el porcentaje del tiempo de proyecto dedicado a la planifiación siguen siendo prácticamente
el mismo, lo único que cambia es la manera en que lo utilizo. Además debemos recordar que el enfoque
de iteraciones o incrementos vs secuencias o procesos predictivos se da en el desarrollo y no en la
planificación, pero si es en esta etapa donde se determina cual enfoque o estrategia utilizaremos para
desarrollar o ejecutar el trabajo.

La Planificación del Alcance

58
Esta etapa inicia como una continuación de la anterior (Inicio), con esto queremos decir que los primeros
pasos de esta etapa pretenden terminar de comprender con profundidad lo que debemos entregar, para
solo así poder establecer o estimar el detalle de lo que debemos hacer, así, esta etapa inicia con el
proceso de Recolección de Requerimientos, el cual no debe confundirse con el proceso de
Levantamiento de Requerimientos que mencionáramos en la sección anterior, ya que el segundo es un
proceso desarrollado para crear un SOW (o casos de USO/Backlog del Producto en métodos ágiles),
mientras que el primero se utiliza para comprender a detalle un SOW o Backlog del Producto claramente
definido.

Por lo tanto, el proceso de Recopilar o recolectar requerimientos tiene como objetivo terminar de
comprender que se requiere del proyecto, entendiendo que dentro del mismo, como en todo proyecto,
existen principalmente dos tipos de requerimientos, a saber:

1. Requerimientos del producto: se refiere a todas las funcionalidades y características que el

producto que el proyecto entregue DEBE tener para garantizar la satisfacción del cliente y la
consecuente generación de beneficios para la organización del cliente.
2. Requerimientos del proyecto: son todos los aspectos que son requeridos para el correcto
desempeño o ejecución del trabajo del proyecto (administración, entrega y apoyo), de ahí que
podríamos tener requerimientos organizacionales (tanto de la organización del cliente como de
la organización ejecutora), regulatorios, de mejores prácticas o estándares.

Como resultado de este proceso generaremos una artefacto o documento conocido como Matriz de
Requerimientos o Matriz de Trazabilidad de Requerimientos, en la que estarán o deben estar
debidamente “mapeados” todos los requerimientos del proyecto que permitan lograr aceptación del
producto y el correcto fluir del desarrollo del proyecto.

Un ejemplo de Matriz de Requerimientos es el que se muestra a continuación, y como puede observarse,

como en todo proceso de gestión, la simplicidad debiera ser siempre una premisa, ya que el objetivo de
gestionar y de las herramientas para ello debe ser siempre facilitar la toma decisiones de los interesados.

59
*****ejemplo Matriz de requerimientos****

Así como podemos discernir, como entradas fundamentales para este proceso tenemos el SOW/Backlog
del Producto, Contratos, Procedimientos organizacionales, Estándares y regulaciones o reglamentos, y
la correcta ejecución de este proceso, obligará al PM a una revisión detallada de todo lo anterior, lo cual,
sin duda le permitirá tenera una comprensión bastante acertada del entorno del proyecto y de las
expectativas de los distintos stakeholders.

Una vez que tenemos claro que se requiere entregar y que se requiere para ejecutar, podemos entonces
comenzar a organizar el trabajo, y para ello comenzamos entonces por definir dicho trabajo, el cual en
el argot del Project Management se conoce como Alcance del proyecto. Este trabajo (alcance),
contempla todo lo que deberá realizarse dentro de los tres tipos de trabajo que hemos venido
mencionando:

1. Administrativo: todos los esfuerzos relacionados a la iniciación, planificación, dirección,

monitoreo y control y cierre de etapas o del proyecto como un todo, el cual es desarrollado por
el PM o por un Equipo de Gestión cuando la cantidad de personal en el proyecto así lo amerite.
2. Entrega: todos los esfuerzos necesarios para la adecuada creación y entrega del producto que
el proyecto debe entregar, el cual es realizado por el Equipo del proyecto.
3. Apoyo: todos los esfuerzos que las áreas de soporte de la organización, es decir las que no son
parte del Core del negocio, sino que lo apoyan, conocidad como Áreas Funcionales, por ejemplo
Recursos Humanos, Compras, Logística, Tecnologías, Finanzas, etc, que son necesarios para que
el equipo tenga los insumos para poder ejecutar el trabajo de entrega de manera correcta.

La correcta definición del Alcance resulta esencial para el éxito del proyecto, ya que como veremos más
adelante, el alcance es la base para la planificación de los demás aspectos del proyecto, como los
recursos, riesgos, calidad, tiempos, costos, adquisiciones, entre otros.

Para la planificación del alcance tenemos los procesos:

1. Recopilar requerimientos ya descrito, y desarrollado para definir el alcance del producto como
tal.
2. Desarrollar la declaración del alcance, proceso mediante el cual se crea un documento que
define el trabajo del proyecto de manera general, usualmente circunscrito a la etapa de
ejecución del proyecto, y referenciando el esfuerzo o trabajo de entrega, por ejemplo Diseño y
Construcción de….., Implementación y Migración de……, Transición y Transformación de……., o
Transferencia de…….. Los trabajos o esfuerzos de administración y apoyo usualmente no son
descritos en dicho documento, y precisamente es lo que hace que en muchas ocasiones no se
documenten y terminen NO ejecutándose, de ahí, que la mejor práctica sea al menos
referenciarlos y detallarlos en el siguiente paso del proceso.

60
 3. El último proceso dentro de la planificación del Alcance es la creación de la Estructura Detallada
de Trabajo (EDT) o WBS por su nombre en inglés (Work Breakdown Structure). El producto de
este proceso es una estructura jerárquica que debe reflejar TODO el trabajo que debe realizarse
en el proyecto, y la cuál, si es construida de la manera correcta, resulta ser quizás, la herramienta
más poderosa para el PM.
Precisamente es que proponemos como mejor práctica, que el PM se asegure de que su
Estructura de Trabajo (WBS) contemple en su nivel más alto los tres tipos de trabajo y de ahí en
adelante continúe su descomposición sin sobrepasar un cuarto nivel, para evitar caer en sobre
descomposición. Lo anterior no quiere decir que la WBS no pueda descomponerse en más
niveles, pero desde la perspectiva de gestión, resulta poco práctico para un PM gestionar una
WBS con Paquetes de Trabajo en niveles inferiores al cuarto, recordemos que en la etapa de
desarrollo el trabajo del PM será el de Dirigir y Controlar el Trabajo y NO de ejecutarlo.
Así, podemos definir como una estructura ideal para un WBS de la siguiente manera:

La Planificación de Recursos

Una vez descrito y aceptado el Alcance, podemos entonces a organizarlo, comenzando por la
identificación de los Recursos Necesarios para llevarlo a cabo.

61
Para el desarrollo del Trabajo (Alcance), requeriremos entonces, Recursos Humanos y Recursos
Materiales como insumo para la producción de los Entregables del Proyecto, de ahí que a nivel de
Paquetes de Trabajo definamos que recursos requerimos para la correcta ejecución del mismo.

Nótese que con la descomposición sugerida para la WBS podemos determinar la importancia de
involucrar a las Áreas Funcionales de la Organización Ejecutora en esta etapa de Planificación, ya que
son dichas áreas las que podrán proveer la información sobre los recursos, riesgos, tiempos y costos
asociados a las labores o trabajos que serán responsabilidad de ellas.

Como resultado de este proceso, podremos contar con lo siguiente:

a) Roles definidos para la ejecución de cada tipo de trabajo y de los paquetes de trabajo
establecidos
b) Descripción de los puestos, esto es, competencias, conocimientos y habilidades necesarias
para cada uno de dichos roles, para un correcto desempeño del trabajo que será asignado
c) Un organigrama del Proyecto que muestre las relaciones de reporte y comunicación dentro
del proyecto
d) Una matriz de Responsabilidades que nos permita reflejar las responsabilidades de cada rol
por tipo de trabajo.

Con respecto a la Matriz de Responsabilidades, resulta importante indicar el cuidado que debemos
mantener al crearla, sin importar el tipo de matriz que se utilice, sea una RACI por sus siglas en inglés (R=
Responsible (Ejecuta), A= Accountable (Responsable), C= Consulted (Consultad@) e I= Informed
(Informad@)), o cualquier otra, debe prestarse especial atención a que la misma se debe construir con
la WBS y el Organigrama, con el objetivo de aprovechar su potencial, como herramienta de
comunicación y generadora de compromiso. De manera errónea, muchos PMs construyen esta matriz
utilizando el Cronograma del proyecto, algo que a estas alturas de la planificación, no hemos construido
por un lado, y por otro, algo que nos lleva al “Micro-management”, diluyendo el potencial de la
herramienta para lograr compromisos y transparencia.

Así, una matriz de responsabilidades debiera verse algo así: CORREGIR

La Planificación de los Riesgos

62
Una vez se tienen claro los recursos tanto humanos como materiales para cada paquete de trabajo,
podemos entonces comenzar a analizar el riesgo asociado a cada trabajo, según los recursos que estamos
considerando asignar. Este proceso de Identificación y Análisis de Riesgos, tiene como objetivo principal,
contar con un Plan de Respuesta para los Riesgos potenciales del proyecto, también conocidos como
“Conocidos-desconocidos”, así como una reserva para gestionar los imprevistos, también conocidos
como “desconocidos-desconocidos”.
Existe mucha teoría alrededor de la gestión de riesgos, la cual resulta de igual aplicación en muchas
industrias y prácticas, como la financiera, corporativa y la de proyectos, dicha teoría plantea los riesgos
tanto como positivos y negativos (oportunidades y amenazas correspondientemente), sin embargo, en
este texto nos referiremos a los riesgos como situaciones que de ocurrir, pueden afectar de manera
negativa el proyecto, es decir amenazas.
El proceso de planificación de la gestión de los riesgos tiene como objetivo, primero que nada identificar
que puede salir mal en el proyecto, de ahí que la manera correcta de identificar que puede salir mal, sea
a través del trabajo que debemos realizar, así, tendremos una tipificación de los riesgos según el tipo de
trabajo al que se relacionen de esta manera:

La tabla anterior nos permite reforzar el hecho de utilizar la WBS como la base para la identificación de
Riesgos. El producto de este proceso será una Lista de Riesgos que podremos analizar tanto cualitativa
como cuantitativamente, para priorizarlos y determinar la mejor respuesta según su prioridad.

63
Para realizar el análisis cualitativo, necesitamos comprender que TODO Riesgo tiene dos cualidades
básicas, que son, Probabilidad (P) de ocurrencia, e Impacto (I) en el proyecto en caso de ocurrir. Así,
para cada riesgo identificado, indiferentemente del tipo, deberíamos determinar tanto la Probabilidad
de ocurrencia así como su impacto; para ello, ya existen matrices de rangos sobre impactos, tipificados
alrededor de las variables más críticas que determinan el éxito del proyecto (tiempo y costo), y la
organización debiera de tener data o información estadística para poder determinar la probabilidad de
cada riesgo. Con estas dos variables podemos determinar lo que llamaremos Exposición al Riesgo = P x
I, donde (I) se utiliza en formato de porcentaje a partir de alguna escala establecida por la organización
o la industria.

****Imagen escalas de impacto*****

Con la exposición entonces podremos Clasificar los riesgos en Muy Altos, Altos, Moderados, Bajos y
Muy Bajos, algo que será muy importante para poder continuar con el análisis cuantitativo o pasar
directamente a la planificación de respuestas.
Según la clasificación de los riesgos podemos determinar la respuesta “tipo” más “alineada” con ese
nivel, dentro de las que tenemos, Evitar, que entendemos como cambiar el plan de acción, Transferir,
es decir pasar el riesgo a un tercero, sea por medio de un subcontrato, garantía o seguro, algo que NO
elimina el riesgo, pero que reduce la Exposición, debido a que impactamos directamente la probabildad
de ocurrencia, nótese el vínculo entre la gestión de riesgos y la gestión de las adquisiciones; Mitigar,
ésta es la respuesta mayormente utilizada, y la misma implica la utilización de las prácticas de calidad
(aseguramiento y control) para disminuir la probabilidad de que los errores lleguen al cliente, nótese el
vínculo entre la gestión de riesgos y la gestión de la calidad; Aceptar Activamente, o lo que es lo mismo,
establecer contingencias para gestionar estos riesgos en caso de que ocurran, nótese el vínculo entre la
gestión de riesgos y la gestión del cronograma y de los costos; Aceptar Pasivamente, o lo que es lo
mismo, no hacer “nada”.

La estimación de Reservas de Contingencia:

Las reservas de contingencias son los tiempos o costos adicionales que asignaremos a ciertos paquetes
de trabajo o etapas del proyecto que así lo requieran según nuestro análisis y planificación de respuestas
a los riesgos. Para ello, se utilza el método conocido como Valor Monetario Esperado (EVM por sus siglas
en inglés), para los riesgos que son de clasificación baja, o para los riesgos residuales después de aplicada
alguna de las estrategias de Transferencia y/o Mitigación.

Así, tenemos la expresión:

EMV = Probabilidad (P) x Impacto (I)

64
Dicha expresión se utiliza entonces para el cálculo de las reservas asociadas a cada riesgo que lo amerite,
considerando el Impacto Estimado ya sea en días o en costo según la variable que sea más crítica.

Del párrafo anterior podría uno inferir cual es la estrategia óptima según la prioridad del riesgo, algo que
desde nuestra perspectiva sería algo así:

Notas:
a. Cuando indicamos respuesta “ideal” queremos decir, que de ser posible aplicar dicha
estrategia, esta debiera aplicarse, aunque tenemos muy claro que en muchas ocasiones
puede no ser posible y debe aplicarse alguna otra, o una combinación de respuestas.
b. En la mayoría de los casos aplicamos un conjunto de respuestas, Mitigamos y después
aceptamos activamente o pasivamente, Transferimos y después mitigamos, y después
aceptamos.
c. Las estrategias de Evitar y Transferir generan Riesgos llamados Secundarios o Colaterales,
los cuales, por definición debieran ser de menor prioridad que el riesgo principal.
d. La estrategia de Mitigar usualmente deja un “remanente” conocido como Riesgo Residual,
el cual debe ser gestionado también.
e. Para la determinación de las Reservas de Contingencia se utilizan la Probabilidad (P) del
riesgo asociado y el Impacto (I) ya no en rangos sino en valores tangibles, es decir ($ o días
(Tiempo))

65
La Planificación de la Calidad

Como resultado de nuestra planificación de respuesta a los riesgos, tenemos no solo información sino
estrategias para actuar, de ahí que podamos definir los criterios de aceptación para cada uno de los
entregables del proyecto, que son parte del alcance, así como las actividades de calidad necesarias para
mitigar los riesgos. Así, para planificar la calidad del proyecto, utilizaremos el WBS (Entregables) y las
respuestas de Mitigación del analisis de Riesgos. El objetivo de este proceso es poder contar con una
Lista de Verificación que nos permita lograr la aceptación de los entregables que hayan sido Verificados
contra los criterios de aceptación definidos y aprobados por el Cliente. Tendremos entonces algo así:

Aparte de esto tendremos identificados los estándares de calidad que apliquen a los tres tipos de trabajo
(Administración/Gestión, Entrega y Apoyo) y los procesos de Control y aseguramiento de la calidad como
estrategias de mitigación de riesgo.

66
La Planificación del Tiempo o Cronograma

A esta altura de la etapa de planificación, contamos con la información necesaria para crear un
cronograma que podamos validar contra el tiempo de restrición establecido en el Acuerdo/Contrato y
reflejado en el Charter. Podemos entonces descomponer los paquetes de trabajo del WBS en
Actividades, las cuales podemos organizar en el orden lógico de ocurrencia (conocido como secuenciar),
podemos asignar los recursos que identificamos anteriormente y determinar tiempo para cada una de
ellas.

67
Una vez que tengamos los tiempos de las actividades podemos entonces estimar la duración de cada una
de nuestras secuencias, conocidas como “caminos” para determinar cual de tod@s es el más largo, ya
que este será la menor duración posible del proyecto según nuestra asignación de recursos, actividades
de calidad para mitigar riesgos y la inclusión de las contingencias de tiempo, también conocidas como
“colchones” o “buffers”. Ese camino más largo, se conoce como la Ruta Crítica del Proyecto, y la razón
principal de determinarla en esta etapa, es tener una base para validar contra el tiempo de restricción
que se nos ha asignado para el proyecto (el que está en el acuerdo y el charter); a esta validación se le
conoce como la determinación de la Holgura del Proyecto y la expresión que la denota es la siguiente:

Holgura del Proyecto (Hp) = Tiempo de Restricción (Tr) – Ruta Crítica (RC)

De esta expresión podemos inferir y concluir lo siguiente:

1. Si Hp = Tr – RC es menor que 0, estamos en problemas; el tiempo que nos asignaron o se

acordó para el desarrollo del proyecto y la correspondiente entrega del producto o
generación de beneficios, es INSUFICIENTE.
2. Si Hp = Tr – RC es igual a 0, estamos en el límite; el tiempo que nos fue asignado o que se
comprometió es exacto al de la ruta crítica, lo que hace el proyecto más riesgoso.
3. Si Hp = Tr – RC es mayor que 0, estamos “sobrados”; el tiempo asignado para el desarrollo
del proyecto y entrega del producto, es mayor que el que necesitamos para la correcta
ejecución del mismo y entrega satisfactoria del producto según nuestras estimaciones y
supuestos.

De lo anterior, podemos concluir, que el PM, tiene la responsabilidad de asegurarse que su proyecto, se
encuentra en el escenario número 3 (tres), dado que este es el único escenario en el que podrá
“garantizar” el cumplimiento de los objetivos.

En cualquiera de los otros dos escenarios, el PM tiene la responsabilidad de analizar la posibilidad de

convertir su realidad en una que refleje el escenario 3, y para esto tiene solo dos caminos posibles:

1. Comprimir su Cronograma, o lo que se conoce como hacer “Compresión del

Cronograma”, y que implica reducir la duración de la RC del proyecto.
2. Informar a su Patrocinador o Sponsor que necesita más tiempo para poder llevar a
cabo el proyecto de la manera correcta.

Dentro del análisis de Compresión, el PM cuenta con dos herramientas o formas para hacerlo, agregando
más recursos a las actividades (Crashing), o programando de manera concurrente, actividades que
normalmente serían secuenciales (Fast Tracking), como se muestra en la siguiente figura.

****Imagen Crashing y Fast Tracking*******

68
Resulta muy importante indicar que los impactos de dichas prácticas deben de considerarse según el
entorno del proyecto, esto debido a que por ejemplo, el Crashing implica un aumento en los costos del
proyecto al utilizar o asignar más recursos, mientras que el Frast Tracking, por su naturaleza, implica un
aumento en el riesgo del proyecto y un muy posible impacto en la calidad del producto.

En caso de que ninguno de los dos métodos citados sea aplicable o posible, el PM tiene la responsabilidad
de optar por el camino 2 (dos) indicado antes, y proceder a informar y solicitar una ampliación del tiempo
a su Patrocinador, quien en defecto, tendrá la responsabilidad de tomar la decisión de negociar o no con
el Cliente, el tiempo ya acordado y que está reflejado en el acuerdo.

Según la decisión del Patrocinador, el PM tendrá entonces un escenario para proceder o tomar una
decisión al respecto:

1. Estar en un escenario positivo para el desarrollo del proyecto.

2. Aceptar un escenario negativo y asumir las consecuencias del mismo.
3. Rechazar el proyecto em el escenario negativo y buscar nuevos rumbos. Entendemos que
esto puede ser muy difícil de asimilar para el lector, e incluso no considerar esta una opción,
sin embargo, es una muy viable y responsable con uno mismo, y con el equipo al que será
eventualmente el proyecto.

Ese Cronograma, con la RC validada y acordada, será entonces la Línea Base del Tiempo del Proyecto, y
por lo tanto, será la que se utilice para Controlar el Rendimiento del proyecto durante las etapa de
Desarrollo y Cierre.

La Planificación de los Costos

69
Ya con una línea base de Tiempo acordada y aceptada, podemos entonces proceder a estimar los costos
del proyecto, considerando los recursos asignados a cada una de las actividades junto con la duración de
las mismas, incluyendo también los costos asociados a las actividades de calidad y de gestión de riesgos,
así como las Reservas de Contingencia estimadas.
El Objetivo de la estimación de los costos, al igual que con los tiempos o cronograma, es el de validar si
el costo asignado para la correcta ejecución del proyecto dentro del plazo establecido y la entrega
adecuada del producto es suficiente, algo que se conoce como “Conciliación del Límite de
Financiamiento”
Entonces, tenemos que podemos estimar los costos del proyecto de varias maneras, que se conocen
como ascendentes o descendentes, las cuales discutiremos brevemente:
1. Estimación Análoga: este tipo de estimación es la que usualmente se utiliza en las etapas
previas al proyecto, cuando se realiza el Caso de Negocio, con el objetivo de tomar
decisiones de Alto nivel, y consiste en estimar realizando una analogía con proyectos
similares anteriores de la organización. Esta estimación, es bastante vaga, debido a que
ignora o no considera las características únicas del proyecto y el producto en cuestión que
lo diferencias de los anteriores, sin embargo es una buena herramienta para tomar
decisiones estratégicas en etapas bien tempranas. Se conoce como una estimación
descendente debido a que se estima para todo el proyecto.
2. Estimación Paramétrica: cuando la organización cuenta con data de rendimiento sobre la
ejecución de actividades y utilización de materiales o maquinaria, el PM puede entonces
realizar cálculos sobre los costos de cada actividad utlizando esta data y las estimaciones
particulares del proyecto en cuestión. Considerando que estas estimaciones se hacen a nivel
de las actividades, que constituyen el nivel más bajo de la descomposición jerárquica del
proyecto, se conoce como una estimación ascendente.
3. Estimación por Tres Valores (PERT): este tipo de estimación, se puede realizar también a
nivel de las actividades, y por lo tanto es también clasificada como ascendente. Para estimar
es necesario contar con información histórica o al menos varios escenarios de la o las

70
 actividades debido a que se necesitan tres valores para calcular la estimación, siendo estos,
el Más Probable (M), el pesimista (P) y el Optimista (O). Con estos valores podemos estimar
usando la siguiente expresión:

Te = (P + 4M + O) / 6
Esta técnica se conoce también como Project Evaluation Review Technique (PERT).

Resulta importante indicar que estos métodos de estimación pueden utilizarse de igual manera para
estimar los tiempos del proyecto, y que en ambos casos, lo que se conoce como el Juicio Experto, es
decir la experiencia del PM y del o los equipos del proyecto resulta ser la principal herramienta para la
estimación.

Una vez agregados los costos, es decir totalizados para todo el proyecto, debemos entonces comparar
el total con la restricción de presupuesto establecida para el mismo (Límite de Financiamiento), ese que
nos es dado y que está reflejado tanto en el acuerdo como en el Charter del Proyecto.

Esto podemos entonces reflejarlo con la siguiente expresión:

Capacidad de Maniobra (Cm) = Límite de Financiamiento (Lf) – Presupuesto Estimado (Pe)

Cm = Lf -Pe

Al igual que en el caso del Cronograma, tendremos tres escenarios posibles, con sus respectivas
consecuencias y decisiones asociadas:

1. Si Cm = Lf - Pe es menor que 0, estamos en problemas; el presupuesto que nos asignaron o

se acordó para el desarrollo del proyecto y la correspondiente entrega del producto o
generación de beneficios, es INSUFICIENTE.
2. Si Cm = Lf - Pe es igual a 0, estamos en el límite; el presupuesto que nos fue asignado o que
se comprometió es exacto al estimado, lo que hace el proyecto más riesgoso.
3. Si Cm = Lf - Pe es mayor que 0, estamos “sobrados”; el presupuesto asignado para el
desarrollo del proyecto y entrega del producto, es mayor que el que necesitamos para la
correcta ejecución del mismo y entrega satisfactoria del producto según nuestras
estimaciones y supuestos.

Una vez más el PM tendrá que tomar una decisión según el escenario que enfrente, o pide más recursos,
o reduce el alcance del proyecto.

71
La Planificación de las Adquisiciones

Un aspecto fundamental para ir concluyendo la planificación del proyecto, es la identificación de que

servicios, actividades deben de adquirirse de afuera de la organización ejecutora, debido a que no son
parte de su “Core”, o debido a que el riesgo de ejecutarlos resulta ser alto y por lo tanto es mejor
tercerizarlo, y qué productos externos son necesarios para la correcta ejecución de las actividades del
proyecto y la producción o creación del producto o entrega del mismo.
Para cada adquisición, el PM debe tener claridad de la forma en que la misma deba ejecutarse, debe
comprender como proceder y qué políticas debe seguir para llevarlas a cabo.
En la mayoría de las organizaciones a nivel global, el PM no es quien ejecuta las labores de adquisición,
sin embargo, el o ella es el último responsable de que todas estén debidamente identificadas,
organizadas y de que sean ejecutadas, para que así el equipo del proyecto y el proyecto como tal,
cuenten con todos los servicios, recursos e insumos necesarios para el desarrollo del proyecto, y es
precisamente el objetivo de este proceso, contar con una clara definición de cuándo y cómo debe
ejecutarse cada adquisición, tomando en cuenta el proceso de adquisición, sus restricciones, tiempos y
responsabilidades.
A pesar de que cada organización Compra o adquiere recursos a su manera, contemplando sus propias
políticas y sistemas, el proceso de adquisición de un bien o servicio es bastante estándar o similar de
manera global y el mismo contempla los siguientes pasos para cada adquisición:

1. El PM debe definir el producto, recurso, bien o servicio que necesita, o lo que es lo

mismo, crear el SOW (especificaciones técnicas) específico para cada adquisición.
2. Debe determinar el método idóneo para la adquisición así como el Tipo de Contrato,
según lo que se vaya a adquirir.
3. Solicitar información, ofertas o propuestas (RFI, RFQ o RFP por sus siglas en inglés
respectivamente)
4. Analizar las ofertas o propuestas y Seleccionar la mejor opción para el proyecto.
5. Negociar con el provvedor seleccionado

72
 6. Asegurar que se firme un contrato o se genere una orden de compra, según
corresponda o se determine.

Todo lo anterior, el PM debe contemplarlo en la planificación, consultando con las áreas funcionales
correspondientes que proveeran apoyo en la consecución de ello, sea Legal (firma de contratos),
Logística (transporte y suministro de insumos), Recursos Humanos (contratación de personal), Compras
(contratación de servicios y materiales) o Tecnologías de Información (entrega de accesos, etc) por
ejemplo.

Tipos de Contrato

Existen tres tipos de contratos principales, de los cuales se derivan varios subtipos, cuyo funcionamiento
todo PM debe comprender, de manera que en conjunto con las áreas de Legal y de Compras de su
organización pueda determinar el idóneo según el tipo de adquisición que se requiera.

Los tres Tipos Generales son:

1. Precio Fijo:
En este tipo de contrato, el cliente y el proveedor acuerdan un Precio Fijo por los servicios
o bienes que el segundo entregará al primero. En este escenario, el proveedor asume TODO
el riesgo del negocio, y por lo tanto usualmente el precio tiende a ser un poco mayor que
con otros tipos de contrato, el comprador o cliente, desconoce el margen de utilidad del
proveedor. El más sencillo de este tipo de contratos es una Orden de Compra.
Es un tipo de Contrato muy útil cuando el producto que se debe entregar está claramente
definido, por lo que el esfuerzo y recursos necesarios pueden estimarse certeramente.
Tiene varias modificaciones que incluyen incentivos por entrega temprana o mejoras en la
calidad del producto.

2. Costo Reembolsable:
Es un tipo de contrato en el que los riesgos son compartidos entre el comprador y el
proveedor, útiles en escenarios donde el producto no está claramente definido. Tiene
variaciones con incentivos según lo que sea más importante, entregar a tiempo o la calidad
del producto por ejemplo. También funciona para proyectos de larga duración donde las
variaciones en costos se consideran dentro del modelo.

3. Tiempo & Materiales:

Para escenarios en los que lo que se necesitan son Servicios, los cuales están claramente
definidos, pero la cantidad de los mismos no se tiene muy clara, este tipo de contrato resulta
particularmente útil.

73
La Planificación de las Comunicaciones y la Gestión de las partes Interesadas (Stakeholders)

Se dice que el tiempo de un PM es para Comunicarse, lo cual resulta ser bastante acertado, si
consideramos, que el trabajo del proyecto es realizado por personas (los equipos de gestión, de proyecto
y las áreas de apoyo), es patrocinado por organizaciones o personas, y el producto es recibido, probado,
validado y utilizado por personas, todas, con expectativas de información del proyecto, que deben ser
satisfechas, para que el flujo del proyecto en su ciclo de vida, sea el adecuado.

Una correcta gestión de las comunicaciones, una correcta distribución, almacenamiento, generación y
disposición de la información es la mejor herramienta para mantener a los interesados involucrados con
el proyecto, y disminuir la probabilidad de que alguno(s) interrumpan el desarrollo del mismo.

Debido a lo indicado anteriormente, es que la Planificación de las Comunicaciones es tán importante

para el PM.

A estas alturas de la etapa de planificación, ya hemos organizado el trabajo que debe realizar, hemos
asignado y distribuido responsabilidades, hemos identificado y planificado respuestas a los riesgos,
determinado los criterios de aceptación de los entregables y el producto final, hemos identificado
estándares o regulaciones que deban seguirse para el desarrollo del proyecto, y hemos programado el
curso de las actividades y los costos asociados para las mismas, y hemos verificado que los tiempos y
recursos dados para el proyecto son suficientes.

Podemos entonces, teniendo claridad de cómo estará organizado todo, y quienes son las partes
interesadas de cada aspecto del trabajo, así como de su ejecución, aprobación y recepción, organizar y
determinar la mejor forma de que dichas partes se comuniquen entre sí, y de que sus expectativas de
información sean satisfechas.

El resultado de este proceso es lo que conocemos como Plan de Comunicaciones, en el cual deberá estar
claramente definido quién comunica a quién, qué se comunica, cómo lo hace (medio), cuándo lo hace y
que intensidad implica.

74
Contar con un buen plan de comunicación le permitirá al PM poder gestionar eficiente y eficazmente las
necesidades y expectativas de información de los stakeholders del proyecto, al mismo tiempo que podrá
llevar a la organización u organizaciones y stakeholders que se vean impactados por el cambio que el
desarrollo del proyecto o la operación del producto generarán, por el proceso de cambio que les permita
adquirir Consciencia del Cambio, adquirir deseo del mismo, conocer el impacto del cambio y adquirir
habilidades nuevas que se requieran en su defecto, incluso reforzando en las etapas de cierre sobre el
mismo. Para esto último puede apoyarse en los procesos de gestión del cambio que existen y que
promueven instituciones como el Change Management Institute, o incluso métodos como los que
plantea la organización PROSCI, conocido como ADKAR.

La Planificación de la Integración

El proceso de consolidar toda la documentación que hemos creado hasta este punto en la planificación,
es el que conocemos como la Creación del Plan de Gestión de Proyecto o Plan para la Dirección del
Proyecto, el cual podríamos decir que es una especie de “Manual” para la correcta utilización de los
documentos producidos en todos los procesos de planificación mencionados antes en esta sección,
dentro de los que podemos citar:

• WBS/EDT
• Backlog del Producto (Scrum)
• Matriz de Responsabildades (RACI)
• Matriz de Riesgos
• Listas de Verificación
• Plan o Matriz de Comunicación
• Cronograma
• Calendario de Liberación (Scrum)
• Presupuesto o Curva S
• Calendario de Compras o Adquisiciones

Junto con otros documentos de gestión tales como plantillas y procedimientos de la organización
ejecutora (conocidos como activos de los procesos organizacionales), o procedimientos o regulaciones
externas (conocidos como Factores Ambientales), y dentro podemos encontrar algunos como:

• Plantillas para Informes

• Plantillas para Minutas
• Plantillas para Actas de Aceptación de Entregas, Productos o Cierre
• Backlog del Sprint (ScrumBoard) (Scrum)
• Sprint Burndown Chart (Scrum)
• Registro de Incidentes o de Situaciones
• Registro de Impedimentos (Scrum)

75
La totalidad de documentos que se utilicen y produzcan durante el desarrollo del proyecto se conocen
como Documentos del Proyecto.

También en dicho Plan debe indicarse la estrategia que seguirá el proyecto, así como los procedimientos
para la correcta ejecución de los trabajos del proyecto:

• Administración o Administrativo::
o Dirección
o Monitoreo & Control
o Cierre
• Entrega:
o Metodología de Desarrollo según las prácticas de la industria a la que “pertenece” el
proyecto o propias de la organización ejecutora
• Apoyo:
o Metodologías, políticas, procesos y prácticas para la ejecución de las labores de apoyo
(Reclutamiento, Compras, Legal, Finanzas, Logística, etc) propias de la organización
ejecutora, y de los departamentos específicos.

Podemos entender entonces el Plan de Gestión como el conjunto de líneas base del proyecto, las
metodologías para la correcta ejecución de los trabajos de Gestión, Desarrollo, Apoyo aplicables al
proyecto, así como las “Instrucciones” para la utilización de los documentos de proyecto/gestión para la
ejecución de las metodologías indicadas.

En el cierre de la etapa de Planificación, es responsabilidad del PM, lograr la aprobación y acuerdo del
Cliente con respecto al plan, así como del patrocinador en caso de ser necesario, para entonces, sólo
entonces, realizar o llevar a cabo el Kick Off o Reunión de Lanzamiento del Proyecto.

Así, podemos decir entonces, que el Objetivo de la Planificación sería el de contar con el trabajo del
proyecto debidamente organizado, con líneas base debidamente Validadas y aprobadas, todo aprobado
por el cliente y comunicado a TODOS los Interesados o stakeholders.

Siendo así, estaremos listos para iniciar con la etapa de Desarrollo del proyecto, es decir, comenzar con
la ejecución de los trabajos que nos permitirán producir y entregar el producto o servicio, e iniciar
entonces con la generación de beneficios asociados.

Etapa de Desarrollo

Como hemos indicado en capítulos anteriores, esta etapa es la que usualmente recibe mayor atención
debido a que en ella se produce el producto o servicio del proyecto, de ahí que en proyectos internos,
para mi cliente o la organización que utilizará el producto y por lo tanto recibirá el beneficio, y para
proyectos externos, para mi patrocinador o la organización que recibirá beneficio (pagos) por la entrega
de productos o servicios al cliente, sea la más importante.

76
En esta etapa se ejecuta el trabajo de entrega como hemos citado anteriormente, de ahí que la misma
se descomponga y tenga nombres propios según la industria en la que nos encontremos. Además,
cuando las organizaciones dicen “hagamos las cosas ágiles”, usualmente se refieren a esta etapa como
tal, y particularmente se refieren a lo que conocen, es decir, al trabajo de entrega del proyecto, al cual
los otros dos tipos de trabajo (Adminitración y Apoyo) deben entonces adaptarse.

Desde la perspectiva del trabajo administrativo o de administración, el cuál es el que nos compete, y el
cuál también resulta ser el mismo, sin importar la industria en la que nos encontremos, y que por lo tanto
tampoco se debe ver afectado en cuanto a responsabilidades y objetivos según el trabajo de entrega que
se esté haciendo, si puede verse afectado por la estrategia de ejecución de ese trabajo de entrega (ágil,
secuencial, iterativo, incremental, etc).

Dentro de las responsabilidades generales del PM en esta etapa tenemos la correcta Dirección del
Trabajo del Proyecto (administrativo, entrega y apoyo), la Gestión de los Equipos del Proyecto, el control
del rendimiento del proyecto, la toma de decisiones para mejorar el desarrollo, el control de los cambios
al mismo, y la correspondiente aceptación de las entregas o productos que se produzcan en esta etapa,
con el objetivo de transicionar o dar paso a la etapa de Cierre del proyecto.

Así, podemos distribuir los trabajos de administración en trabajos de Ejecución (Dirección) y trabajos de
Monitoreo & Control, los cuales tienen como entrada lo producido en la etapa de planificación y en los
procesos de planificación como tal, los cuales discutiremos a continuación con detalle, considerando que
en esta etapa también pueden presentarse procesos de Inicio, Planificación y Cierre dependiendo de la
cantidad de sub-etapas que tenga esta etapa.

77
Los Procesos de Dirección (Ejecución)

Para la correcta ejecución de estos procesos contamos con los procedimientos y metodologías definidos
específicamente para el proyecto o identficados de la organización, así como los estándares y
regulaciones identificados que afecten el desarrollo del proyecto y específicamente los procesos de
dirección como tal.

Todo PM, sin importar el tipo de organización en la que se encuentre, y por lo tanto sin importar el nivel
de autoridad que tenga, es resposable último del correcto funcionar del equipo del proyecto, y de la
correcta interacción con los equipos de apoyo y gestión si es que estos últimos están presentes en el
proyecto.

Debido a ello, es que el ejercicio personal de un PM como líder, con el desarrollo implícito de las
competencias que le atañen, así como un claro entendimiento del entorno en el que se desarrolla el
proyecto (tipo de organización a la que pertenece la organización ejecutora, el giro del negocio, así como
el tipo de organización del cliente si el proyecto es externo) y una clara comprensión de los beneficios
que se esperan del producto del proyecto y su relevancia estratégica son críticos.

Competencias como el análisis crítico del entorno, la toma de decisiones, comunicación asertiva y
empática, vulnerabilidad, desarrollo de otros (mentoring, coaching), facilitación, asertividad, orientación
a resultados y pensamiento estratégico entre otras son fundamentales para un desempeño adecuado de
los procesos en cuestión, y por lo tanto de vital importancia en el desarrollo de carrera y personal de
alguien que busque desarrollarse como PM.

La Dirección del Trabajo y de los Equipos del Proyecto

78
Este proceso, como lo denota su nombre, se refiere a las actividades que todo PM debe desarrollar para
procurar que el equipo o los equipos del proyecto produzcan lo resultados que fueron planificados y que
son los que permitirán cumplir con el objetivo del proyecto (entregar el producto o servicio que generará
beneficio).

Para Dirigir el trabajo el PM cuenta con varios insumos de la etapa de planificación como lo son la
WBS/EDT, Matriz de Responsabilidades que muestra de manera general las responsabilidades de los
distintos interesados, la Matriz de Riesgos, , el Cronograma del proyecto (particularmente la Ruta Crítica
del mismo o el Calendario de Hitos), el Cronograma de Aquisiciones o Compras así como los
Documentos de las Adquisiciones, a saber los SOW asociados a cada adquisición.

Adicional a esto, debe considerar los procesos de la áreas de apoyo respectivos a Adquisición de
Recursos, Contrataciones, Compras, accesos al proyecto, seguridad, etc, ya que esto no solo pueden
funcionarle, sino que también pueden delimitar la ejecución de sus responsabilidades.

El objetivo último de este proceso es la producción de los Entregables del Proyecto, para ser entregados
al cliente, buscando la aceptación de los mismos, logrando con la aceptación del último entregable o del
producto final del proyecto, finalizar la etapa de Desarrollo, y transicionar entonces a la etapa de Cierre
como tal.

Nótese que si en nuestra etapa de desarrollo, tenemos varias sub-etapas o particiones, tendremos
entonces procesos de cierre de cada una, para proceder a la siguiente, lo que se conoce como Stage
Gates o Toll Gates en PRINCE2 por ejemplo, esto debido a que usualmente cada una de las etapas o sub-
etapas del desarrollo produce uno o más entregables, que deben ser aceptados para poder transicionar
a la siguiente etapa, siguiendo un modelo incremental, progresivo o secuencial.

Si en nuestro proyecto en cambio, hemos decidido utilizar métodos iterativos o ágiles, podremos tener
dentro de la etapa de desarrollo o en alguna de sus sub-etapas, lo que conocemos como iteraciones o
Sprints específicamente dentro del marco de Scrum; dentro de cada iteración o sprint tendremos
entonces una segmentación en tres fases o etapas, conocidas como:

• Planificar & Estimar en la que ocurren procesos de planificación propios de Scrum, en los
que el equipo Central delpara planificar el trabajo del sprint y producir lo que se conoce como
el Backlog del Sprint y el Burndown Chart, que servirán para Dirigir y Controlar el trabajo
dentro de la iteración en cuestion.
• Implementar donde el equipo del proyecto, conocido como Equipo Scrum produce los
entregables, se autogestiona utilzando las herramientas de control creadas en la etapa
anterior, a saber el Scrumboard que es una tabla que contiene entre tres y cuatro columnas
por las que “viajan” o transicionan las actividades planificadas o definidas para el sprint, estas
columnas se conocen como (TO DO) que es donde está el trabajo pendiente para el sprint al
inicio de la fase de implementación, es decir el Backlog del Sprint, (WIP : Work in Progress)
que es donde estará el trabajo que esté ejecutándose y (DONE) que es la columna donde
estará el trabajo que haya sido finalizado según las especificaciones definidas, en ocasiones
se incluye una cuarta columna entre el WIP y el DONE conocida como (TEST) en donde se

79
 colocan las actividades o entregas que se encuentran siendo probadas o verificadas; y el
Burndownchart, el cual es un gráfico de control que muestra la velocidad ideal que debiera
seguir el equipo para “quemar” el trabajo, es decir, realizarlo; dicho gráfico se construye
asignando puntos a cada actividad del Backlog del Sprint ubicada en la columna de TO DO,
en función del esfuerzo que cada una requiera, para posteriormente totalizar la cantidad de
puntos para el sprint al inicio y la cantidad esperada al final de esta etapa de implementar,
es decir 0 (cero) puntos.

A continuación se muestran ambas herramientas como referencia, no sin antes indicar que estas son
herramientas de control que funcionan para el equipo del proyecto, NO para comunicar a Mandos
medios o altos, que más bien prefieren Cronogramas los primeros y Calendarios de Hitos o de
Liberaciones los segundos.

ScrumBoard

TO DO WIP TEST DONE

Burndown Chart

Puntos del Sprint

Duración del Sprint

• Revisión y Retrospectiva: En esta etapa ocurren dos procesos críticos de la Agilidad, quizás los
dos más valiosos al utilizarla, ya que los mismos son los que permiten adaptarnos y ser flexibles,
principios básicos de la agilidad. Dichos procesos ocurren en dos reuniones específicas que el
equipo Scrum realiza con el Product Owner, y con el Scrum Master respectivamente; el primer
proceso se conoce como Revisión del Sprint y ocurre en una reunión llamada Reunión de
Revisión del Sprint, donde el Equipo le presenta al Product Owner el resultado del sprint, es
decir el entregable, el cuál debió haber sido verificado con anterioridad, de ahí la columna de
TEST que algunas personas incluyen en el ScrumBoard; es decir, que lo que ocurre en dicha

80
reunión y proceso es una validación del Alcance (Aceptación del Entregable) o rechazo del
mismo por parte del Producto Owner quien es la Voz del Cliente (VOC). El segundo proceso de
esta etapa lleva el nombre Retrospectiva del Sprint y ocurre en una reunión llamada Reunión
de Retrospectiva en la cual el equipo Scrum, Facilitado por el Scrum Master, analiza que salió
bien y mal del sprint recientemente finalizado para establecer que debe mejorarse o cambiar
para la siguiente iteración, sea la cantidad de trabajo que se incluirá (Puntos del Sprint),
asígnación de tareas, estrategia de ejecución, etc, todos aspectos que serán considerados en la
etapa de Planificar & Estimar del próximo Sprint.

Nota: un error muy comúnmente cometido al utilizar el método, es considerar que la duración
del Sprint no incluye las tres etapas citadas, lo que automáticamente impacta la duración del
proyecto. Así, si se ha determinado una duración del sprint de 4 semanas (20 días), debemos
considerar que necesitaremos al menos 1 día para el Planificar y Estimar, y uno o dos para la
Revisión y Retrospectiva, lo que quiere decir que para el Implementar tendremos realmente 17
o 18 días realmente.

81
 Capítulo 6

El Marco de Referencia del Project

Management Institute (PMI®)

Ya en capítulos anteriores hemos citado al Cuerpo de Conocimiento de la Administración de Proyectos

(PMBOK® Guide) por sus siglas en inglés, el cual es el Marco de Referencia por excelencia para la gestión
de Proyectos, de hecho, otras organizaciones como la International Project Management Association
(IPMA®) lo utiliza como base complementaria a su Marco de Referencia propio. De la misma manera, la
mayoría de los profesionales del mundo del PM, habrán escuchado del PMBOK® Guide o habrán tenido
algún contacto con el mismo.
Este Marco, es un estándar reconocido por el American Norms and Standarization Institute (ANSI), lo
que hace que, de manera errónea, muchas personas se refieran al mismo como una metodología. La
frase, “aquí hacemos proyectos según la metodología PMI®”, es de las barbaries más utilizadas por los
desconocedores de la materia, cuando tratan de aparentar que conocen.
Actualmente se encuentra en su sexta edición, y el mismo es revisado cada cuatro (4) años por un grupo
Global de centenas de Voluntarios bajo la tutela y supervisión del PMI®, con el objetivo de validar la
vigencia de las prácticas definidas en el mismo, así como la inclusión de nuevas prácticas y tendencias.
La primera edición fue publicada en 1996, y la última (Sexta edición) saldrá al mercado en todos los
idiomas en junio 2017.
Dentro de los aspectos fundamentales que plantea el PMBOK® Guide, y que de alguna u otra manera
han ayudado a definir la profesión se encuentran los grupos de proceso y las áreas de conocimiento que
plantea el cuerpo, siendo estos así:

Grupos de Procesos de la Gestión de Proyectos:

1. Grupo de Procesos de Inicio
2. Grupo de Procesos de Planificación
3. Grupos de Procesos de Ejecución
4. Grupos de Procesos de Monitoreo & Control
5. Grupos de Procesos de Cierre

Áreas de Conocimiento de la Gestión de Proyectos:

1. Área de Conocimiento de la Integración

2. Área de Conocimiento del Alcance
3. Área de Conocimiento del Cronograma
4. Área de Conocimiento del Costo
5. Área de Conocimiento de la Calidad
6. Área de Conocimiento de los Recursos

82
 7. Área de Conocimiento de la Comunicación

PMI y PMBOK son marcas registradas del Project Management Institute, Inc

8. Área de Conocimiento de los Riesgos

9. Área de Conocimiento de las Adquisiciones
10. Área de Conocimiento de los Interesados

83
 Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Sixth Edition, Project
Management Institute, Inc., 20011, Tabla 1-4, Página 25

PMI es una marca registrada del Project Management Institute, Inc

84
Cada una de las áreas citadas contiene uno o más procesos, los cuales se distribuyen entre los distintos
grupos de procesos; así, por ejemplo, podemos observar como el Grupo de Procesos de Planificación es
el único Grupo de Procesos que contiene procesos de TODAS las áreas, y que el área de conocimiento de
la Integración, es la única área que contiene procesos en TODOS los grupos de Proceso.

En el texto, las distintas áreas de conocimiento se desarrollan en el mismo orden que se plantean en la
lista anterior, lo que lleva a muchas personas con y sin experiencia en el tema del Project Management,
a erróneamente interpretar que ese es el orden en que se ejecutan los procesos durante el ciclo de vida
del proyecto, algo incorrecto a todas luces.

Como bien se indica en el texto, los grupos de proceso pueden ocurrir dentro de cada una de las etapas
del proyecto, según se determine para la realización del proyecto como tal.

Grupos de Procesos de Dirección de Proyectos

Grupo de Procesos de Inicio:

Este grupo de procesos está compuesto por “aquellos procesos realizados para definir un nuevo proyecto
o una nueva fase de un proyecto existente, al obtener la autorización para iniciar el proyecto o fase.”
(PMI, 2013)

El mismo incluye procesos de las áreas de Integración (Creación del Charter) e Interesados (Identificación
de Interesados).

Grupo de Procesos de Planificación:

Contempla todos los procesos necesarios para “establecer el alcance total del esfuerzo, definir y refinar
los objetivos, y desarrollar la línea de acción requerida para alcanzar dichos objetivos.” (PMI, 2013). El
objetivo último del mismo es sin duda contar con un Plan de Gestión que permita dirigir el proyecto y
que funcione como línea base para el control. Como bien se indica en el texto, la naturaleza incierta,
propia de los proyectos, requiere en muchas ocasiones, que este proceso de planificación sea iterativo,
por lo que los procesos que pertenecen a este grupo, pueden ocurrir varias veces durante el ciclo de vida
del proyecto.

Es el único grupo de procesos que contiene procesos de TODAS las áreas, y en algunos casos, más de un
proceso por área, como sucede con el Alcance, Tiempo, Costos y Riesgos.

PMI es una marca registrada del Project Management Institute, Inc

85
Grupo de Procesos de Ejecución:

A pesar de que tiene un nombre que en muchas ocasiones resulta confuso para el practicante y el lector,
estos procesos son realmente los procesos que el PM ejecuta para poder dirigir, por lo que debieran
entenderse como procesos de Dirección, y contempla “aquellos procesos realizados para completar el
trabajo definido en el plan para la dirección del proyecto a fin de cumplir con las especificaciones del
mismo” (PMI, 2013); en este grupo de procesos, es que el PM invertirá la mayor parte de su tiempo
durante la etapa o etapas de desarrollo, ya que el mismo incluye los procesos enfocados a la gestión del
equipo del proyecto, así como la distribución de información (comunicaciones) y la gestión de
interesados.

Contempla o incluye procesos de las áreas de Recursos, Comunicaciones, Interesados, Adquisiciones,

Calidad e Integración.

Grupo de Procesos de Monitoreo & Control:

Estos procesos son fundamentales para controlar no solo el rendimiento del proyecto como tal, sino la
satisfacción del cliente. De manera errónea se suele decir que “estamos en la etapa de control”, cuando
es claro que el monitoreo & control son procesos administrativos que se realizan mientras el trabajo o
esfuerzo se ejecuta. Este grupo está compuesto por “aquellos procesos requeridos para rastrear, analizar
y dirigir el progreso y desempeño del proyecto, para identificar áreas en el que plan requiera cambios, y
para iniciar los cambios correspondientes” (PMI, 2013).

Desde la perspectiva de los interesados, es quizás el grupo de procesos más importante, pues es el que
brinda visibilidad sobre el desempeño y los resultados del proyecto, de ahí que se confunda con una
etapa debido a su importancia.

Incluye procesos de las áreas que contienen líneas base, a saber, Alcance, Tiempo y Costo, así como
procesos de Riesgo, Calidad, Adquisiciones, Interesados y Comunicaciones.

PMI es una marca registrada del Project Management Institute, Inc

86
Grupo de Procesos de Cierre:

Este Grupo de Procesos, a pesar de tener pocos procesos (solo dos (2)), tiene muchísima importancia
dentro de la gestión, ya que contiene procesos críticos para garantizar la transición del producto del
proyecto a operaciones o al cliente, así como la liberación de los recursos y su correspondiente
asignación a otros proyectos, otras áreas de la organización o fuera de la misma.

Contiene los procesos “realizados para finalizar todas las actividades a través de todos los grupos de
procesos de la dirección de proyectos, a fin de completar formalmente el proyecto, una fase del mismo
u otras obligaciones contractuales” (PMI, 2013)

Está conformado por los procesos de las áreas de Adquisiciones (Cerrar Adquisiciones) e Integración
(Cerrar fase o proyecto).

PMI es una marca registrada del Project Management Institute, Inc

87
Áreas de Conocimiento de la Dirección de Proyectos

El PMBOK® Guide define un área de conocimiento como “un conjunto completo de conceptos, términos
y actividades, que conforman un ámbito profesional, un ámbito de la dirección de proyectos, o un área
de especialización” (PMI, 2013). Así, no deberían tomarse las diez áreas que citamos con anterioridad y
que desarrollaremos con más detalle en los próximos párrafos, como únicas y exclusivas, sino, que es
muy probable, que, según el tipo de proyecto, otras áreas específicas deban agregarse o considerarse,
como, por ejemplo, finanzas.

Dentro del marco de SCRUM® por ejemplo, a las áreas de conocimiento, como hemos citado antes, se
les conoce como Aspectos, y de hecho no se incluyen todos, algo que citaremos y desarrollaremos en
capítulos posteriores.

Gestión de la Integración

La Gestión de la Integración, podría decirse, que, define el rol del PM, ya que en ella se definen o
contemplan los procesos necesarios para “identificar, definir, combinar, unificar y coordinar los
diferentes procesos y actividades de dirección del proyecto.” (PMI, 2013) Dichos procesos son la base
para poder ejecutar las actividades o labores de Iniciar, planificar, dirigir, controlar y cerrar el proyecto
como tal.

Es la única área de conocimiento que tiene procesos en todos los grupos de proceso, y está conformada
por los siguientes procesos:

1. Crear el Acta Constitutiva del Proyecto (Project Charter) – Proceso de Inicio: este es el proceso
mediante el cual el PM, crea un documento que formalmente autoriza el proyecto. Un
documento que incluye información de carácter general del proyecto como el Producto que
debe entregar, el plazo que se tiene para realizarlo (definido por el cliente-patrocinador), y el
presupuesto para desarrollarlo (definido por el patrocinador). Este documento de carácter
interno de la organización ejecutora del proyecto, lo autoriza el Patrocinador y le confiere
autoridad al PM para utilizar los recursos de la organización ejecutora para llevar a cabo el
proyecto.
2. Desarrollar el Plan de Gestión de Proyecto – Proceso de Planificación: Con el desarrollo de este
proceso, el PM consolida los resultados de la Planificación de las otras áreas de conocimiento,
integrando todo en un SOLO documento que funcione como el “manual” para la ejecución,
dirección, control y cierre del proyecto. El producto de este proceso, el Plan de Gestión del
Proyecto, es quizás el documento más importante para el PM, contiene referencia a las líneas
base del proyecto (Alcance, Tiempo y Costo), definición de criterios de aceptación de los
entregables del mismo (Calidad), estructura organizacional necesaria (roles y
responsabilidades), y metodologías de gestión para llevar a cabo los procesos de Dirección

PMI y PMBOK son marcas registradas del Project Management Institute, Inc

88
 (Ejecución), Monitoreo & Control y Cierre, en las etapas subsecuentes del proyecto. El Hito que
permite evidenciar el fin/cierre de la planificación e inicio del desarrollo, es el “Kick-off” o
Lanzamiento del Proyecto, un evento (reunión), donde el PM, comunica a todos los interesados
el Plan como tal, que previamente ha sido aprobado por el Cliente. Debe tenerse claro también
que la salida o salidas de este proceso, son entonces, el Plan de Gestión y la presentación
(Materiales) para el “Kick-off”, y que se tienen como complemento al Plan de Gestión, lo que se
conoce como Documentos de Gestión, los cuales son salidas de los procesos de planificación de
las otras áreas de conocimiento.

**** figura Plan de gestión vs documentos de gestión****

3. Dirigir y gestionar el Trabajo de Proyecto – Proceso de Ejecución: este es “el proceso de liderar
y llevar a cabo el trabajo definido en el Plan para la Dirección del Proyecto, e implementar los
cambios aprobados, para alcanzar los objetivos del proyecto.” (PMI, 2013). Como bien se ha
mencionado anteriormente, y como bien lo indica el PMBOK® Guide, el beneficio o fin último de
este proceso es proporcionar dirección al proyecto. Dado que este proceso ocurre durante toda
la etapa de desarrollo del proyecto, y como bien hemos observado, esta es usualmente la etapa
más larga, es usualmente donde el PM consume la mayor parte de su tiempo, precisamente
dirigiendo al equipo, y gestionando a los distintos interesados, distribuyendo información del
estado del proyecto, así como incidentes, situaciones o cambios que ocurran. Quizás el principal
objetivo de este proceso sea la producción y entrega de los entregables del proyecto, para que
los mismos puedan ser verificados y validados posteriormente para su respectiva aceptación;
junto con los entregables, también se generan los resultados del trabajo como tal, información
pertinente al avance de cada uno de los entregables y el trabajo en general
Precisamente, en ese proceso de Dirección, es que se identificarán tanto acciones preventivas,
como correctivas y reparación de defectos, responsabilidad del PM, en lo que respecta a la
implementación de las mismas, y a partir de esta acción se tendrán quizás solicitudes de cambios
al plan aprobado en la etapa de planificación o etapas de desarrollo previas.

4. Monitorear y Controlar el trabajo del Proyecto – Proceso de Monitoreo y Control: este proceso
ocurre en paralelo al proceso de Dirigir y Gestionar el Trabajo del Proyecto, y resulta ser de
carácter complementario al mismo. Para este proceso tenemos como entrada los entregables y
los datos del rendimiento que mencionamos anteriormente, como insumos para tomar
decisiones y acciones. Ejecutando este proceso, el PM estará en la capacidad de demostrar a los
interesados “el estado actual del proyecto, las medidas adoptadas, y las proyecciones del
presupuesto, el cronograma y el alcance” (PMI, 2013). Así, resulta indispensable para el PM,
tener claridad, previo al desarrollo o la ejecución de este proceso, el cual es continuo a lo largo

PMI y PMBOK son marcas registradas del Project Management Institute, Inc

89
 de TODO el ciclo de vida del proyecto, la información que cada interesado necesita para la toma
de decisiones que puedan afectar el proyecto. Dentro de las actividades específicas que este
proceso contempla se encuentran:
a. Comparar el desempeño REAL del proyecto contra el PLAN
b. Identificar nuevos riesgos y monitorear los existentes
c. Proporcionar información sobre el estado de “salud” del proyecto, así como
proyecciones del mismo
d. Monitorear la implementación de los cambios aprobados al plan
e. Mantener satisfechas las necesidades de información de los distintos interesados del
proyecto
5. Realizar el Control Integrado de Cambios – Proceso de Monitoreo & Control: “es el proceso
que consiste en analizar todas las solicitudes de cambios, aprobar los mismos, y gestionar los
cambios a los entregables, los activos de los procesos de la organización, los documentos del
proyecto (documentos de gestión) y el plan para la dirección del proyecto, así como comunicar
las decisiones correspondientes” (PMI, 2013). Este, es quizás, uno de los procesos de gestión
más críticos para un PM, ya que, la mayoría de proyectos, muestran una inadecuada gestión de
los cambios, que al final se traduce en atrasos, sobrecostos, inconformidades y otros del
proyecto. EL principal beneficio para un PM, de la adecuada ejecución de este proceso, es la
reducción o disminución del riesgo de que algunas de las situaciones mencionadas ocurran.

PMI es una marca registrada del Project Management Institute, Inc

90
 Capítulo 7

Proyectos en ambientes controlados

(PRINCE2®)

91
 Capítulo 8

Agile Project Management y el Marco de

Referencia del Scrum®

92
 Capítulo 9

El Dilema del Líder – PM

Liderazgo 101

La construcción de Relaciones

Pensamiento Estratégico

Orientación a Resultados

Ejecución

93
 Capítulo 10

Gestión de Programas de Proyectos

94
 Capítulo 11

Gestión de Portafolios de Proyectos

95