Manual para Project Managers Cómo Gestionar Proyec... - (PG 42 - 392)

40 Introducción
Su identificación no es inmediata ni estática en la vida del proyecto, ya que pueden

aparecer nuevos interesados conforme avance el proyecto, y su nivel de interés, impacto
y relevancia en el proyecto puede cambiar sustancialmente.
Son un elemento clave en un proyecto porque pueden hacer que sea un éxito o
que fracase. Por mucho que el producto haya sido entregado a tiempo y se hayan satis-
fecho los objetivos del proyecto, si los interesados clave no están contentos, el proyecto
no habrá sido un éxito.
Si bien se tratarán con más detalle en el capítulo 2, se puede avanzar que los más
habituales son el patrocinador (sponsor) –suele ser un ejecutivo de la organización con
autoridad para asignar recursos e instar a tomar decisiones relativas al proyecto–, el pro-
ject manager, el cliente final, el consejo de dirección, la alta dirección, los directores
funcionales de otros departamentos, los vendedores, los proveedores, el equipo de tra-
bajo…
En la figura siguiente se presentan los más habituales:
En la figura siguiente se presentan los más habituales:
Copyright © 2018. Wolters Kluwer España. All rights reserved.
Es muy importante identificar a todos los interesados de un proyecto porque si se

olvida uno importante y no se descubre hasta bien avanzado el proyecto, puede tener
un gran impacto negativo en el mismo o, en el mejor de los casos, crear problemas y
trabajos imprevistos.
Los interesados suelen tener intereses contrapuestos –y es responsabilidad del project
manager identificar, entender y tratar de resolver los conflictos que puedan aparecer–
e, inevitablemente, tienen expectativas respecto al proyecto que también el Project
manager tendrá que gestionar reuniéndose con ellos para identificar sus necesidades.
De hecho habrá partes interesadas en positivo pero también interesadas en negativo.
No todas las personas con las que se trabaja estarán deseando que el proyecto sea un
Echeverría, Jadraque, Daniel. Manual para Project Managers: cómo gestionar proyectos con éxito (3a. ed.), Wolters Kluwer España, 2018.
ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=5426609.
Created from unadsp on 2020-07-19 10:03:33.
Proyecto y dirección de proyectos 41
éxito. Pueden pensar que el proyecto va a tener consecuencias negativas para él o ella
y tratarán de ralentizarlo o abortarlo.
En estos casos el project manager tendrá que gestionar las expectativas de estas per-
sonas y trabajar con ellas para buscar objetivos que compartan y con los que se sientan
cómodas explicándoles bien el porqué del proyecto y las ventajas que traerá. El project
manager necesitará saber qué motiva a cada una de las partes interesadas si quiere conocer
cuál será su influencia y de qué signo en el proyecto.
En concreto, los pasos que se verán con más detalle al describir el proceso de iden-
tificar a los interesados son:
• En primer lugar saber quiénes son.
• Determinar sus expectativas y requerimientos.
• Evaluar sus conocimientos y habilidades.
• Analizar el proyecto para asegurar que sus necesidades y expectativas van a
tenerse en cuenta.
• Involucrarlos en el proyecto:
– Informándoles.
– Solicitándoles su criterio en los cambios y en la creación de lecciones
aprendidas.
– Asignándoles trabajo si procede.
– Utilizándoles como expertos.
– Y obteniendo su aprobación formal durante el cierre.
Si los proyectos no tuvieran ningún tipo de limitación los project managers no serían
necesarios porque no haría falta nadie con la habilidad para gestionar las seis restricciones
más habituales que necesariamente tendrá el proyecto (o buena parte de ellas). Pero,
afortunadamente para la profesión, los proyectos suelen tener muchas partes interesadas
cuyos intereses gestionar y las siguientes restricciones (constraints) que equilibrar:
Tiempo (Time) El proyecto debe estar listo para una fecha determinada.
Coste (Cost) El proyecto no deberá sobrepasar el coste aprobado.
Alcance (Scope) El proyecto tiene que incluir lo acordado y nada más y nada menos.
Recursos (Resources) El proyecto tiene recursos humanos y materiales limitados.
Calidad (Quality) El proyecto debe tener los requisitos de calidad acordados.
Riesgo (Risk) Obstáculos inesperados pueden dar al traste con el proyecto.
El project manager, con el acuerdo de las personas interesadas, deberá tomar deci-
siones del tipo:
– El proyecto no va a cumplir plazos y decide entregarlo en plazo pero dejar
algunos elementos del proyecto para más adelante (gestionando el alcance).
42 Introducción
– El equipo de trabajo quiere que se haga una segunda tanda de ensayos pero el
project manager, de forma justificada y profesional, considera que ya son sufi-
cientes (gestionando la calidad).
– El project manager no tuvo en cuenta los costes de las licencias de los programas
lo que ha hecho que el presupuesto se desvíe (gestionando los costes).
– Y muchas otras similares en las que deberá valorar los impactos en las seis res-
tricciones.
En síntesis, un proyecto será exitoso si cumple las expectativas de los interesados
concretadas en los requerimientos del producto y el proyecto por lo que éstos son un
condicionante esencial que debe considerar el project manager.
La gobernanza de los proyectos (Project Governance)

La gobernanza de los proyectos es una función supervisora a lo largo del ciclo de
vida de los proyectos definida en la organización. Facilita al project manager una estruc-
tura, procesos y modelos de decisión para gestionar los proyectos y lograr los objetivos
de la organización. La gobernanza de proyectos tiene que ver con el objetivo de que
éstos estén alineados con la estrategia y objetivos de la empresa. Es un conjunto de
procesos que permite a la organización identificar oportunidades, realizando los corres-
pondientes casos de negocio, y traducirlas, cuando proceda a proyectos.
Es un marco en el que se definen procesos y se asignan roles y responsabilidades para
que se aborden los mejores proyectos y se inicien de la forma adecuada.
Entre los aspectos que incluye la gobernanza de proyectos están los criterios de
evaluación de los proyectos –necesariamente alineados con los objetivos estratégicos de
la compañía–, los procesos para evaluar, priorizar, asignar recursos y aprobar el inicio
de un nuevo proyecto, el ciclo de vida del proyecto establecido en la organización –y
que depende de los procesos de decisión establecidos y de los productos y/o servicios
que produzca la organización–, entre otros aspectos.
1.2.4.2. La influencia del equipo de proyecto

El equipo de proyecto lo forman las personas que apoyan al Project manager en la
ejecución de los trabajos para completar los entregables del proyecto y cumplir sus
objetivos. En este grupo está el propio Project manager, el equipo de dirección del
proyecto y otras personas que realicen tareas de ejecución del proyecto.
Entre los roles que puede haber en los equipos de proyecto están el equipo de
dirección del proyecto (Project management team) que ayudan en las labores de gestión
al Project manager, los expertos de apoyo (supporting experts) que realizan las tareas
necesarias para llevar a cabo lo establecido en el Plan de Proyecto –finanzas, logística,
compras...–, los clientes y usuarios (users or customers) que son las personas de la orga-
nización que deben aceptar y aprobar los entregables una vez validado el alcance y los
socios y proveedores (sellers/business partners).
Los equipos de proyecto pueden tener una dedicación total o parcial al proyecto,
estar ubicados geográficamente en el mismo lugar o ser equipos virtuales y pertenecer
a la misma organización o a varias con acuerdos generales o específicos para el proyecto.
1.2.4.3. El ciclo de vida del proyecto
Ciclo de vida del proyecto (Project Life Cycle)

El ciclo de vida de un proyecto es el conjunto de fases que proporcionan un marco
de referencia para dirigir el proyecto, desde su inicio hasta su fin, independientemente
del trabajo específico involucrado:
Las fases en las que se divide un proyecto, y que conectan el principio con el final
del mismo, describen qué hay que hacer para finalizar el trabajo, qué desarrollar en cada
fase, cuándo hay que generar los entregables, cómo se van a revisar y validar, quién
estará involucrado y cómo se controlará y aprobará el cierre satisfactorio de cada fase y
el inicio o no de la siguiente.
En muchas organizaciones el ciclo de vida o fases del proyecto suelen están definidas
de antemano mientras que en otros pueden definirse dependiendo de las características
del proyecto o no dividirse en fases. El ciclo de vida de los proyectos de una organización
puede, de hecho, estar definido como parte de la gobernanza de los proyectos y los
procesos de aprobación de inversiones.
Entre las características de las fases están que:
• Pueden configurarse dentro de una estructura del ciclo de vida del tipo inicio,
organización y preparación, ejecución del trabajo y cierre.

• Se delimitan por transiciones de una fase a otra que requiere de alguna forma
de transferencia, entregable o producto.
• Se producen revisiones al final de cada fase y estos puntos de revisión y apro-
bación (o rechazo) se conocen como salidas de fase, hitos (milestones), puertas
de fase, puntos de decisión, puertas de etapa o puntos de cancelación (phase
gates, decision points, state gates or kill points).
• Que tras esa revisión se determina si el trabajo puede continuar a la siguiente
fase, requiere corregir errores o ejecutar más trabajos.
• Que, en general las fases son secuenciales (se inicia una cuando acaba la prece-
dente) aunque veremos que puede haber excepciones.
Si el proyecto es de larga duración, complicado o las inversiones en él van aumen-
tando conforme avanza se suele ejecutar en diferentes fases. Pero cada fase se gestiona
utilizando los cinco grupos de procesos (inicio, planificación, ejecución, seguimiento y
cierre) que veremos posteriormente, como si cada una fuera un subproyecto.
44 Introducción
ISO21500 considera también que los proyectos pueden dividirse en fases –que incluyen
unos trabajos y entregables finales específicos– que son determinadas por la gobernanza de
proyectos en la organización y las necesidades de control y que al conjunto de estas fases se
denomina ciclo de vida del proyecto.
Entre dos fases consecutivas se definen puntos de decisión en los que se evalúa la conveniencia
o no de pasar a la siguiente fase, reconsiderar el proyecto o aparcarlo.
Proyecto con varias fases

Este esquema presenta cómo estos grupos de procesos están relacionados con las
fases de un ciclo de un proyecto (en este caso, secuencial, al no empezar la fase siguiente
hasta finalizar la anterior):
Este esquema nos permite a su vez ver las diferencias entre las fases (1 a 4, en el
esquema) que forman el ciclo de un proyecto, los grupos de procesos necesarios para la
gestión de cada fase y, con todos, el proyecto global.
Dirección y gestión del proyecto a lo largo de su ciclo de vida

La decisión sobre cómo se va a gobernar el proyecto debe describirse en el Plan de
Dirección del Proyecto (Project Management Plan). Deben tomarse decisiones con
respecto a quién participará, qué recursos se necesitarán y el enfoque general para com-
pletar el trabajo, así como si el proyecto tendrá una o varias fases.
En caso de ser varias las fases, se definirán los criterios para revisar los entregables o
productos finales de cada fase y tomar la decisión de seguir adelante o no. El inicio de
una nueva fase es un momento para revalidar los supuestos previos, revisar los riesgos y
definir más detalladamente los procesos necesarios para completar los entregables.
Por lo general, una fase concluye con la revisión y verificación de su finalización y
aceptación, buena práctica para determinar si el proyecto:
• Debe avanzar hacia la siguiente fase,
• o corregir errores (cuanto antes de detectan, menor es el coste de su corrección).
• o dejarlo parado o abandonarlo.
Relaciones entre fases

Hay tres tipos de relaciones entre fases:
• Secuencial (Sequential): una fase debe acabarse antes de que empiece la
siguiente.
• Con solapamiento (Fast tracking): una fase empieza antes de que haya acabado
la precedente (aumentando los riesgos de errores, correcciones…).
• Con iteraciones (Iterative): el trabajo de fases posteriores se planifica –pero no
se ejecuta– mientras el trabajo de la fase anterior está en ejecución.
Las fases del proyecto forman parte del ciclo del proyecto. Y en buena parte de los
proyectos las fases tienen las siguientes características en común:
• Al inicio del ciclo de vida del proyecto, cuando el proyecto se inicia, los costes
son bajos y todavía hay pocas personas asignadas al proyecto.

• Conforme el proyecto progresa los costes y el personal crecen y luego desapa-
recen a su conclusión.
• La probabilidad de que el proyecto sea exitoso es menor al principio, y ésta crece
conforme el proyecto avance en sus fases sucesivas.
• Los riesgos son mayores al principio y se reducen conforme el proyecto se acerca
a su fin.
• Las partes interesadas tienen mayor capacidad de influencia en la definición del
proyecto y en las características del producto o servicio y una mayor oportunidad
de hacerlo en las fases iniciales, y menos conforme avanza el proyecto.
La figura siguiente muestra gráficamente las características indicadas:
46 Introducción
Tipos de ciclos de vida de proyectos

Existe gran cantidad de enfoques metodológicos para la gestión de proyectos –con
mayor o menor aceptación- por lo que elegir el que mejor encaje con nuestro proyecto
es a veces complejo.
Dentro de los distintos enfoques metodológicos existentes, cabe destacar dos grandes
grupos:
Predictivos
Se centra principalmente en la predictibilidad del proyecto y por tanto dedica gran
esfuerzo a una detallada y minuciosa planificación del proyecto. Esto hace que en tiempo
de ejecución, el seguimiento y control del mismo se simplifique, pudiendo reportar
fácilmente la situación del proyecto en todo momento y tomar medidas si fueran nece-
sarias.
La contrapartida de este enfoque es que el exceso de detalle en la planificación
conlleva cierta resistencia al cambio, por lo que proyectos altamente cambiantes se
resienten con enfoques predictivos.
Habitualmente estos proyectos se gestionan de acuerdo a una serie de fases secuen-
ciales o ligeramente secuenciales. El trabajo realizado en cada fase es normalmente de
naturaleza diferente al ejecutado en la fase precedente y posterior.
Ágiles o adaptativos
El enfoque ágil para la gestión de proyectos se centra principalmente en ofrecer el
máximo valor posible con los recursos disponibles para el proyecto, dedicando un menor
esfuerzo a la planificación del mismo y centrándose en la priorización del trabajo a

realizar y la gran adaptabilidad a los cambios.
Es un enfoque muy adecuado para entornos de alta incertidumbre donde se esperan
muchos cambios a lo largo de la vida del proyecto y es necesaria una adaptación cons-
tante a los mismos.
En estos casos, se define una visión del producto que se traduce en una serie de
requerimientos –pila de producto– priorizados y que se irán ejecutando y añadiendo al
producto en iteraciones con una duración corta, dependiendo del producto y sector.
Al final de cada período se realiza una presentación al cliente o propietario de pro-
ducto quien debe aprobar el incremento de funcionalidad logrado, se realiza una reunión
retrospectiva –con un enfoque de mejora continua– y se procede a actualizar la pila de
producto y, tras la selección de las funcionalidades que se incorporarán en el siguiente
sprint, se vuelve a comenzar el ciclo.
La contrapartida de este enfoque es la baja predictibilidad del proyecto, dificultando
la visibilidad del estado del proyecto y trabajo pendiente hasta su finalización.
Ciclo de vida iterativo e incremental

Un proyecto se llevará a cabo siguiendo una serie de pasos, bien definidos, que
marcarán su ciclo de vida. Dentro de este concepto existen dos enfoques complemen-
tarios:
Iterativo
Un ciclo de vida iterativo implica que el proyecto se divide en fases, que se irán
acometiendo de forma iterativa o cíclica de modo que el equipo está centrado en la fase
N para, cuando la termine, pasar a la fase N+1. Esto permite acometer proyectos grandes
aplicando la técnica «Divide y vencerás», es decir, descomponiéndolos en proyectos de
menor tamaño (fase) y acometiéndolos cada uno de ellos de forma individual, secuencial
y coordinada.
Durante una iteración se ejecutan todos los grupos de procesos de la gestión de
proyectos (desde el inicio hasta el cierre) y al final de la iteración se deben completar
una serie de entregables. Al final de cada fase se revisan los supuestos y se elabora el Acta
de Constitución de los trabajos de la siguiente fase o iteración.
Incremental
Un ciclo de vida incremental complementa al ciclo de vida iterativo, centrándose
en el producto entregado. Por lo tanto, implica iteratividad (descomposición del pro-
yecto en fases), pero con el condicionante de que cada iteración debe aportar una por-
ción del producto final utilizable (incremento).
La ejecución de un proyecto de manera incremental es solo aplicable por tanto a
productos que, por su naturaleza, pueden ir elaborándose en porciones o incrementos
que aporten funcionalidad al cliente final, aun no estando terminado el producto com-
pleto. Un ejemplo de esto es un proyecto de creación de una página Web. El proyecto
48 Introducción
puede descomponerse en varias iteraciones pero haciendo que cada una de ellas cree
una parte de la página Web completa (página incial, información de la empresa, tienda
virtual, zona para clientes, noticias,…).
La gran ventaja de este ciclo de vida es que, en el caso de que el proyecto se cierre
sin haberse finalizado –por falta de presupuesto, fin de plazo máximo, etc.– el producto
entregado aporta valor al cliente, aun no estando completo.
Puerta de una fase (Phase gate)

Se trata de la parte final de una fase, en la que se establece un punto de decisión,
donde el rendimiento y el avance del proyecto global se comparan con los siguientes
documentos:
• Caso de negocio
• Acta de constitución
• Plan de gestión del proyecto
• Plan de gestión de beneficios
En base a dicha comparación, y a la vista de los resultados obtenidos, deberá tomarse
la decisión de continuar con la siguiente fase según lo planificado, continuar con la
siguiente fase introduciendo modificaciones, terminar el proyecto, mantenerse en la fase
actual o repetir la fase completa o parte de la misma.
Diferencias entre ciclo de vida del proyecto, gestión del proyecto y ciclo de
vida del producto
El ciclo de vida del proyecto son las fases en que se divide un proyecto (viabilidad,
ingeniería preliminar, prototipo, prueba real) e indica el trabajo que se necesario realizar.
El ciclo de vida de la gestión de un proyecto se divide en cinco grupos de proceso:
inicio, planificación, ejecución, supervisión y control y cierre. En el caso de un proyecto
con varias fases o subproyectos, estos cinco grupos se repiten dentro de cada fase o
subproyecto.
El ciclo de vida del producto (Product Life Cycle) es una serie de fases del producto
que puede comenzar con su diseño, su lanzamiento al mercado, su vida útil y su dete-
rioro y eliminación.
1.2.4.4. Los condicionantes de un proyecto según la ISO21500
ISO21500 define de forma integrada el entorno de la gestión de proyectos en una orga-

nización recogiendo conceptos tratados en el punto 1.2.4.1 y 1.2.4.2 de este libro.
En el siguiente esquema se presenta el entorno general que enmarca y condiciona la gestión
de proyectos de una organización:
Tipos de ciclos de vida de proyectos

Tratamos brevemente los diferentes conceptos que conforman el esquema:

La estrategia de la organización:
Las organizaciones, teniendo en cuenta su misión, visión y valores, establecen unos objetivos
estratégicos. Los proyectos son las acciones encaminadas a lograr dichos objetivos. El objetivo de
un proyecto es dar beneficios medibles que contribuyan a hacer realidad las oportunidades iden-
tificadas. Los objetivos de un proyecto se cumplen cuando se obtienen los beneficios esperados:
La evaluación de oportunidades y el inicio de proyectos:

Se realiza normalmente dentro de lo que, en metodología PMBOK e ISO21500, lla-
mamos gestión de la cartera de proyectos. Las oportunidades se evalúan para informar la toma
50 Introducción
de decisiones por la dirección e identificar proyectos viables que puedan transformar esas opor-
tunidades en beneficios. Las oportunidades se suelen evaluar a través de una serie de actividades
para finalizar con la aprobación formal del inicio de un proyecto. Normalmente se elaborará un
Caso de Negocio que justifique la inversión en el proyecto (y que ayudará en la priorización de
oportunidades y proyectos).
Materializar los beneficios (transición del resultado del proyecto a operaciones):

Es responsabilidad de la dirección de la organización la realización de beneficios utilizando
los resultados del proyecto para el logro de los objetivos de la estrategia.
Por su parte, el responsable del proyecto, project manager, debe tener en cuenta los beneficios
previstos a la hora de tomar decisiones durante el ciclo de vida del proyecto.
Entorno de los proyectos (que afecta a su gestión):
a) Entorno externo a la organización
El entorno externo a la organización puede tener impacto en el desempeño y éxito del
proyecto. Lo conforman los factores socioeconómicos, geográficos, políticos, regulatorios,
tecnológicos, medioambientales... Impondrán restricciones o introducirán riesgos (fuera
del control del responsable de proyecto).
b) Entorno interno a la organización
Entre estos factores están: la estrategia, la tecnología, la madurez en gestión de pro-
yectos, la disponibilidad de recursos, la cultura y la estructura organizativa. También
se incluye la propia organización interna de los proyectos que pueden organizarse en
carteras (portfolios) o programas.
c) La gobernanza de los proyectos
Es el marco en el que una organización dirige y monitoriza sus proyectos. Incluye
aspectos como la estructura de dirección, las políticas, procesos u metodologías a utilizar,
los límites de autoridad en la toma de decisiones, las responsabilidades de las diferentes
partes interesadas, los flujos de reporte y escalado de problemas y riesgos.
La responsabilidad de mantener una adecuada y efectiva gobernanza de proyectos

deberá asignarse de forma clara e inequívoca y al nivel adecuado.
d) Las partes interesadas y la organización de los proyectos
Las partes interesadas en la gestión de proyectos de una organización, con un significado
y alcance similar al indicado en la Guía del PMBOK, deben ser descritas con suficiente
detalle para garantizar el éxito del proyecto.
1.2.5. Qué es la dirección de proyectos

Como introducción –se verá con mucho más detalle en el punto 8-3 Dirección
Estratégica por Proyectos–, en el siguiente esquema se observa:
• La relación jerárquica-funcional de carteras (portfolios), programas (programs)
y proyectos (projects).
• Y su relación con los objetivos estratégicos de la empresa.
Así, los elementos de la parte superior (misión, visión, objetivos estratégicos…)

condicionarán los niveles inferiores (carteras) y éstos condicionarán los situados en la
base (programas y proyectos).
Dirección de Proyectos (Project management)

El project manager y su equipo utilizan una serie de técnicas y herramientas para
describir, organizar, monitorizar y controlar el trabajo de las actividades del proyecto.
Los project managers son los responsables de gestionar los procesos del proyecto y aplicar
las técnicas y herramientas para llevar a cabo las actividades del proyecto.
La dirección de proyectos es un proceso que incluye iniciar un nuevo proyecto,
planificarlo, ponerlo en marcha y ejecutarlo, monitorizarlo y medir el avance y desem-
peño. Implica identificar los requerimientos del proyecto, establecer los objetivos del
proyecto, gestionar las limitaciones, y restricciones y, todo ello, teniendo en cuenta las
expectativas de las partes interesadas.
Planificar es una de las funciones más importantes que el project manager debe
realizar durante el desarrollo del proyecto ya que establece la línea base del avance del
proyecto y se utiliza para seguir el desempeño futuro del proyecto.
ISO21500 define la gestión de proyectos como la aplicación de métodos, herramientas,

técnicas y competencias a un proyecto. Incluye la integración de las diferentes fases del ciclo de
vida del proyecto.
De acuerdo a la ISO21500 la gestión de proyectos se realiza mediante procesos elegidos
y aplicados con una visión sistémica. Cada fase debe tener entregables específicos que deben
revisarse regularmente para asegurarse de que cumplen los requisitos del cliente.
52 Introducción
Gestión de Programas (Program management)

Los programas (programs) son grupos de proyectos relacionados entre sí que se
gestionan utilizando las mismas técnicas y de una manera coordinada para lograr bene-
ficios y sinergias que, de realizarse cada proyecto por separado, no se lograrían. Este sería
el caso de un proyecto que tiene múltiples subproyectos dentro de él y que hay que
gestionar conjuntamente.
Normalmente, cada subproyecto tiene su propio project manager quien reporta al
program manager, responsable del programa completo.
Si, por ejemplo, una compañía quisiera cambiar un sistema de recursos humanos
basado en papel a un sistema basado en software y pasan un tiempo buscando los mejores
programas informáticos para este trabajo y deciden que, finalmente, gestionarán todas
las funciones de recursos humanos conjuntamente ya que necesitan la misma gente para
hacer todo el trabajo, estaríamos hablando de un programa que, a su vez tendría varios
proyectos: el de gestión de nóminas, el de formación, el de desarrollo profesional y
roles…
O, en el caso de que una universidad quisiera crear un sitio Web de admisiones para
todos los departamentos y ve que todos sitios Web van a alimentarse de la misma interfase
de registro, y deciden gestionarlos todos de manera conjunta para ahorrar tiempo, esta-
remos también ante un programa que gestionará conjuntamente los proyectos de los
diferentes departamentos.
La gestión de este grupo de proyectos –determinando su interdependencia, gestio-
nando sus limitaciones y puntos de coordinación, resolviendo los problemas entre ellos,
gestionando de manera centralizada y coordinando grupos de proyectos relacionados
para alcanzar los objetivos del programa– se denomina Gestión de Programas (Program
management).
De acuerdo a la ISO21500 un programa es un conjunto de proyectos y otras actividades

relacionados entre sí, todos ellos alineados con objetivos estratégicos de la organización. La
gestión de programas consiste, por tanto, en actividades centralizadas y coordinadas para lograr
esos objetivos.
Gestión de Carteras (Portfolio management)

Las carteras (portfolios) son grupos de programas y proyectos que apoyan un
objetivo de negocio específico. Es importante resaltar que deben ir enfocados a lograr
un objetivo de negocio estratégico de la empresa. Los proyectos y programas que con-
forman la cartera pueden no ser necesariamente interdependientes o estar directamente
relacionados.
La organización puede tener varias unidades de negocio en el área inmobiliaria. En
este caso, todos los proyectos que hay dentro de cada área de negocio forman un port-
folio. Y el objetivo general de todos los proyectos y programas de este portfolio es
alcanzar los objetivos estratégicos de la cartera y los de ésta, a su vez, lograr los objetivos
estratégicos de negocio de la empresa.
Para aclarar este concepto pongamos dos ejemplos: el primero es una compañía
consultora que quiere incrementar la cantidad de tiempo facturable de cada empleado.
Para ello comienzan varios programas en toda la compañía para ayudar a los consultores
a conseguir aumentar su productividad anual. Lo que estará gestionando será un con-
junto de programas, esto es, un portfolio que además busca un objetivo estratégico:
aumentar la productividad.
En el segundo ejemplo nos encontraríamos con una compañía de juegos de orde-
nador que quiere, como objetivo estratégico, aumentar su presencia on-line. Para
lograrlo lanza varias iniciativas de marketing y ventas, crea algún nuevo juego y actualiza
algunos viejos para conseguir más jugadores on line. Claramente busca un objetivo
estratégico (aumentar su presencia on-line), lanza varios programas (de ventas y mar-
keting) y algunos proyectos (un nuevo juego)… por lo que nos encontramos ante un
portfolio con programas y proyectos.
Podría darse un tercer ejemplo en el que se tienen varios proyectos que sin tener
aparente relación entre sí todos tienen como común el cliente. En este caso se podrían
gestionar cómo un portfolio de programas y/o proyectos referidos a ese cliente.
La gestión de carteras trata de gestionar una colección de programas y proyectos
priorizando los proyectos en relación a los objetivos estratégicos del negocio, supervi-
sando el alineamiento de los proyectos con los objetivos generales y comparando los
proyectos con otras inversiones de la empresa para asegurar el uso más eficiente de los
recursos.
De acuerdo a la ISO21500 una cartera o portfolio de proyectos es un conjunto de programas

y proyectos que se agrupan para facilitar la gestión efectiva de los mismos y alcanzar así los
objetivos estratégicos de la organización.
De esta manera, la gestión de la cartera de proyectos sería la gestión centralizada de uno o
más carteras o portfolios de proyectos lo que incluye identificar, priorizar, autorizar, dirigir y
controlar programas, proyectos y otros trabajos para alcanzar objetivos estratégicos específicos.
Como vemos es una definición muy cercana a la definida por la Guía del PMBOK.
Oficina de Gestión de Proyectos (Project Management Office, PMO)

Son unidades organizativas centralizadas que monitorizan la gestión de los proyectos
y programas de toda la organización para establecer y mantener procedimientos y están-
dares para las metodologías de Dirección de Proyectos y gestionar los recursos asignados
a los proyectos de la organización.
En algunas organizaciones los project managers y equipos de proyecto reportan a la
Oficina de Gestión de Proyectos y es ésta la que los asigna a los nuevos proyectos; en
otras, ofrece servicios de apoyo técnicos (con expertos que ayudan a planificar, estimar
o verificar las hipótesis de partida de los proyectos) y forma a los empleados en los
procedimientos de Dirección de Proyectos.
También suelen mantener y archivar la documentación generada por los proyectos
para uso futuro, comparan los objetivos de los proyectos con los avances y retroali-
54 Introducción
mentan al project manager con sugerencias sobre planes de aceleración, asignaciones de

recursos, revisión de riesgos.
De acuerdo al PMBOK, las oficinas de gestión de proyectos pueden tener tres tipos
de funciones:
• De apoyo: dando soporte y teniendo un papel de órgano consultivo enfocado
a facilitar plantillas, mejores prácticas, acceso a información sobre lecciones
aprendidas de otros proyectos…
• De control: dando apoyo y asegurando que se cumplen los procesos, procedi-
mientos y plantillas y se gestionan los proyectos de acuerdo a las directrices
establecidas en la gobernanza de proyectos.
• De dirección: tomando el control de los proyectos y dirigiéndolos directamente
desde la oficina de gestión de proyectos.
Suelen ser el punto de conexión natural de la estrategia y la gestión de la cartera con
la gestión de proyectos tomando, en algunas empresas, un papel muy relevante en la
ejecución de la estrategia de la organización.
En el punto dedicado a la Dirección Estratégica por Proyectos se presenta con más
detalle los diferentes tipos de Oficinas y los niveles de responsabilidad de cada una. Estos
tipos son según su responsabilidad y su autoridad:
• Centros de Excelencia.
• Oficinas de Apoyo a Proyectos.
• Oficinas de Gestión de Programas.
• Oficinas Responsables de Proyectos.
1.2.6. El valor del negocio (Business value)

1.2.6.1. Documentos de negocio de la gestión de proyectos
El Project manager debe asegurar que el enfoque del proyecto va encaminado a

alcanzar lo descrito en la documentación de negocio existente.
Existen dos documentos de negocio: el Caso de negocio y el Plan de gestión de
beneficios. El responsable de la creación y mantenimiento de dichos documentos es el
patrocinador, mientras que la labor del gestor de proyecto debería ser la de dar suge-
rencias al respecto y trasladar la información clave de los mismos a documentos del
proyecto como el Acta de constitución y el Plan de dirección del proyecto, de modo
que se garantice la alineación entre los objetivos de la organización y los que persigue
el proyecto. Para esta última labor, se apoyará también en el gestor de programa en el
que esté enmarcado el proyecto.
Caso de negocio del proyecto (Project business case)

El caso de negocio se creará como resultado de una demanda del mercado (un nueva
aplicación para móviles), una necesidad de la organización (la implantación de un pro-
ceso de calidad 6 Sigma),una solicitud de un cliente (una mejora sustancial en la maqui-
naria instalada), avances tecnológicos (una nueva aplicación para la nueva generación
de tablets), requerimientos legales (el cumplimiento de la nueva ley de protección de
datos por parte de los sistemas de una entidad bancaria) o por otras razones.
Ahora el objetivo es explicar por qué y cómo atiende el proyecto las necesidades de
negocio y dejar claro que la inversión en el proyecto merece la pena.
Preparar un caso de estudio lleva a reflexionar sobre el valor del proyecto para
nuestro negocio, si hay un mercado suficiente, si hay que hacerlo porque el cliente así
lo ha pedido, si generará sinergias con otras áreas de la empresa…
Si el proyecto:
• tiene demasiado riesgo;
• y/o no va a ser muy rentable;
• y/o no está alineado con la estrategia del grupo;
• y/o hay serias dudas de que vaya a salir adelante;
la alta dirección no lo lanzará. Para valorar su rentabilidad se utilizarán los parámetros
introducidos en el punto 1.2 y explicados con más detalle en el 8.3 «Dirección Estra-
tégica por Proyectos» y 8.1 «Financiación del proyecto».
Es responsabilidad del project manager conocer por qué y para qué se ha seleccio-
nado el proyecto y cómo encaja en el plan estratégico de la organización y tratar de
lograr que el proyecto satisfaga esas necesidades. Lo deberá tener muy en cuenta a la
hora de evaluar el impacto de los cambios que se propongan en la fase de ejecución.
Su contenido normalmente suele ser el siguiente:
a) Necesidades de negocio
• Determinación de la motivación que impulsa la acción.
• Declaración situacional que describa el problema o la oportunidad de
negocio a abordar.
• Valor que aporta a la organización.
• Identificación de los interesados afectados.
• Breve descripción del alcance.

b) Análisis estratégico de la situación que tratará de responder a los cuatro
aspectos anteriores y muy especialmente hacer una estimación cuan-
titativa de la rentabilidad esperada, del volumen de beneficios…
• Identificación de estrategias, metas y objetivos que persigue la organiza-
ción con el proyecto.
• Identificación de las causas raíz del problema o de los principales contri-
buyentes de una oportunidad, según sea el caso.
• Riesgos identificados.
• Principales factores de éxito.
• Identificación de criterios de decisión (requeridos, deseados, opcionales)
• Consideraciones –que pueden ser descritas a modo de escenario empre-
sarial– a tener en cuenta para alcanzar el objetivo de negocio.
56 Introducción
c) Recomendación
• Descripción de la opción recomendada para el proyecto. Dicha descrip-
ción contendrá al menos: los resultados del análisis para la opción reco-
mendada, limitaciones, asunciones, riesgos y dependencias y mediciones
de éxito (criterios de aceptación).
• Adicionalmente se puede acompañar de un enfoque de la implementación
que contendría básicamente: hitos, dependencias y roles y responsabilida-
des.
• Los proyectos relacionados y con los que puede ser complementario,
generar sinergias o en los que se puede fijar para abordarlo y realizar una
buena planificación inicial. Incluso ver si, aunque en este proyecto no se
gane nada, pueda haber proyectos que se beneficien de sus resultados.
d) Evaluación que describirá cómo se va a medir el proyecto con res-
pecto a los beneficios esperados.
Si tras analizar la documentación del proyecto el project manager considera que
el presupuesto aprobado es una limitación que puede impedir el éxito del pro-
yecto y alcanzar los objetivos de la empresa, debe hacerlo saber y solicitar un
aumento del mismo ya que, de otra manera, el proyecto fracasará y el compañía
no alcanzará sus objetivos –y la responsabilidad del fracaso será del project
manager–.
Es responsabilidad del project manager no aceptar un proyecto siendo cons-
ciente que, tal y como está planteado, no va a cumplir sus objetivos.
En el caso de proyectos con fases múltiples, este caso de negocio debe ser revi-
sado periódicamente, preferentemente al final de cada fase y previo al inicio de
la siguiente para ver si las condiciones que dieron lugar a su viabilidad o renta-
bilidad se mantienen o no y, dependiendo del resultado, avanzar o no con la
siguiente fase.
Plan de gestión de beneficios del proyecto (Project benefits management plan)

Se trata de un documento que se elabora en un momento temprano del ciclo
de vida del proyecto que describe aspectos sobre la gestión de los beneficios
esperados del proyecto, marcando:
• Cómo y cuándo se obtendrán los beneficios del proyecto.
• Mecanismos que permitirán medir dichos beneficios.
Un beneficio del proyecto se define como el grado de valor –fruto de los
resultados del proyecto- que aporta a la organización que lo patrocina, así como
a otros posibles interesados.
Habitualmente el plan de gestión de beneficios se compone de:
• Beneficios (tangibles e intangibles) a alcanzar –como por ejemplo un
retorno de inversión de 120M$, una mejora en la imagen de la compañía,
mejora de la productividad, etc).
• Alineamiento estratégico, definiendo cómo se alinean los beneficios del

proyecto con la estrategia de negocio definida para la compañía
• Calendario de obtención de beneficios, marcando por ejemplo los bene-
ficios esperados por cada fase del proyecto.
• Persona responsable de supervisar, almacenar e informar sobre los bene-
ficios obtenidos a lo largo del período de tiempo marcado en el plan.
• Métricas que se utilizarán para medir si se alcanzan los beneficios esperados.
• Asunciones tomadas en el plan para calcular los beneficios esperados.
• Riesgos identificados relacionados con la obtención de los beneficios
esperados.
La elaboración del plan de gestión de beneficios toma como punto de partida
documentos como el caso de negocio o la evaluación de necesidades de negocio.
Este documento refleja, al igual que lo hace el plan de dirección del proyecto,
cómo retorna a la organización el valor del negocio obtenido tras la ejecución
del proyecto. Las métricas definidas son clave para verificar que se ha conseguido
el valor esperado por lo que es clave que estas sean definidas de manera SMART
(eSpecíficas, Medibles, Alcanzables, Relevantes y limitadas en el Tiempo).
El plan de gestión de beneficios no es un documento estático, sino que irá
evolucionando a lo largo del ciclo de vida del proyecto.
Acta de constitución y Plan de dirección del proyecto (Project charter and project mana-
gement plan)
El Acta de constitución es el primer documento –y por lo tanto la base- que se
genera en un proyecto aprobado y sirve para definir los objetivos y autorizar el
comienzo del proyecto. Contiene habitualmente información de alto nivel
sobre el proyecto, así como el nivel de autoridad del Project manager en el
proyecto.
El Plan de dirección del proyecto define con detalle el plan del proyecto y está
compuesto por un conjunto de planes subsidiarios y las líneas base del proyecto.
Ambos documentos se describen en detalle en los procesos correspondientes del
área de conocimiento Gestión de la Integración.
Medición de éxito del proyecto (Project success measures)

Una vez que el proyecto ha finalizado deberá determinarse si ha sido o no exi-
toso. Para poder medir si el proyecto ha sido un éxito deberán definirse unas
métricas que permitan evaluar el grado de éxito del mismo de manera objetiva.
Tradicionalmente las métricas se basaban únicamente en valores de tiempo,
coste, alcance y calidad, pero cada vez es más habitual basarlas en también en
consideraciones del grado de realización de los objetivos del proyecto. Para ello
es clave que los objetivos sean específicos y medibles.
La diversidad de interesados en un proyecto implica diferentes expectativas
puestas en el mismo y conlleva a distintos puntos de vista sobre las métricas de
58 Introducción
éxito del proyecto. El Project manager deberá recoger todas las expectativas y
tratar de llegar a un consenso compartido por todas las partes interesadas al res-
pecto de las métricas a utilizar para medir el grado de éxito del proyecto.
Adicionalmente, deberán considerarse criterios adicionales relacionados con los
objetivos estratégicos de la organización –tales como el retorno de inversión,
payback, ratio coste-beneficio, cumplimiento de términos y condiciones de un
contrato, consecución de estrategias de la organización, alcanzar la satisfacción
de ciertos interesados, etc.–.
Puede ocurrir que un proyecto sea exitoso desde el punto de vista del proyecto
(alcance, tiempo, coste, calidad), pero no desde el punto de vista de negocio
(estrategia). Esto puede ocurrir cuando hay un cambio en las necesidades de
negocio o en el entorno de mercado antes de que finalice el proyecto.
1.2.7. El project manager: funciones y habilidades

Si bien la formación de base del project manager suele ser técnica, el éxito del
proyecto descansa muy fundamentalmente en su habilidad para gestionar e identificar y
resolver problemas interpersonales y de organización, muy sensibles con frecuencia. Es
por ello que sea imprescindible una formación específica en gestión de proyectos.
La Dirección genera ideas y proyectos pero corresponde al project manager evaluar
como implementarlas, confirmar que el proyecto cumple las necesidades y expectativas
del cliente y la dirección y determinar el trabajo que es necesario hacer, el plazo, el coste
y los recursos necesarios.
El project manager debe ser una persona proactiva, con iniciativa, que lidere y que
sepa responder a las reticencias de buena parte de los equipos y organizaciones frente a
un nuevo proyecto: que «no hay tiempo para planificar», que «tenemos que apagar
fuegos», que «esto de la gestión de proyectos es para grandes proyectos», que «su desa-
rrollo requiere creatividad e ir resolviendo los problemas conforme vayan viniendo»…
Son actitudes y prejuicios que la experiencia demuestra que hacen los proyectos más
caros, más largos y más insatisfactorios para la organización y para el cliente.
Funciones y responsabilidades
Su principal responsabilidad es que el proyecto cumpla los objetivos y las expecta-
tivas del cliente y para ello tiene que cumplir las siguientes funciones:
• Desarrollar el Plan de Dirección del Proyecto así como todos los Planes Subsi-
diarios.
• Definir el Alcance del proyecto.
• Seleccionar, conformar y liderar el proyecto.
• Identificar y evaluar a los interesados del proyecto.
• Generar el Plan de Gestión del Proyecto incluyendo el alcance, presupuesto y
cronograma.
• Gestionar y controlar los riesgos.
• Gestionar los cambios en el proyecto.

• Mantener el proyecto en coste y plazo.
• Hacer seguimiento e informar del progreso y estado del proyecto.
Características generales
Las habilidades técnicas que puede tener un buen técnico de la organización no
valen para ser un buen gestor de proyectos. Puede ser un magnífico técnico pero incapaz,
si no tiene las aptitudes y la formación necesarias, para gestionar un proyecto con todo
lo que ello implica. Promocionar a un buen técnico suponiendo que también será un
buen gestor se conoce como «efecto Halo».
Los project manager son generalistas con muchas habilidades en diferentes áreas,
que tendrán un equipo de trabajo que contará con especialistas en diferentes materias y
que serán los que se encarguen de los problemas técnicos.
El project manager, como se ha indicado en la introducción, es un «gerente de una
empresa temporal» que deberá tener unas habilidades generales y otras específicas
dependiendo del sector en el que trabajen (farmacéutico, construcción, agroalimentaria,
aeronáutica…).
Que el project manager tenga un cierto conocimiento del área en el sector que va
a trabajar siempre será un valor añadido siempre que no le lleve a hacer «micro-mana-
gement» y revisar los aspectos técnicos que conoce pero que son responsabilidad ya
asignada a un técnico del equipo de proyecto –dejando de hacer su trabajo de gestión,
coordinación e integración–.
Si bien se tratan de forma más amplia las cualidades directivas y personales de un
project manager en el punto 8.2, se hace a continuación un breve resumen.
Habilidades de comunicación
Es una de las más importantes. La primera causa de fracaso de los proyectos es no
establecer, o establecer mal, los objetivos del proyecto; la segunda, la mala comunicación
entre las partes interesadas –empezando por la comunicación de los propios objetivos
del proyecto–.
Por ello las habilidades de comunicación hablada y escrita son clave para un buen
project manager ya que será el responsable de organizar reuniones, escribir informes de
seguimiento… y deberá hacerlo de manera que los mensajes sean claros, explícitos y
completos para que el receptor no tenga problemas en comprender el mensaje. Una vez
enviado, sigue siendo el responsable de asegurarse de que entiende el mensaje y de hacer
las consultas pertinentes.
Habilidades de organización y planificación

Están relacionadas con las anteriores y son, sin duda, las más importantes para un
project manager. Como project manager manejará mucha y variada documentación que
deberá ser capaz de organizar para tenerla en el momento necesario y plenamente
60 Introducción
actualizada. Asimismo organizará y planificará reuniones, coordinará equipos, gestionará

su tiempo y dará pautas para que lo gestione su equipo priorizando trabajos y acciones.
Habilidades para gestionar costes y presupuestos

Los project managers establecen y gestionan presupuestos y, por ello, necesitan
algunos conocimientos de finanzas y contabilidad. En colaboración con su equipo rea-
lizarán estimaciones de costes para crear el presupuesto global o para estimar un coste
general inicial del proyecto o ir desgranando los costes y afinando el presupuesto del
proyecto conforme éste avance.
Dentro de este área estarán los conocimientos que le permitan leer y comprender
cotizaciones de proveedores, preparar o monitorizar órdenes de compra y facturas…
Habilidades para gestionar conflictos

Gestionar conflictos implica resolver problemas que cada día surgen en el desarrollo
de un proyecto: definiendo el problema, separando las causas raíz de los síntomas, tra-
tando de ver si son problemas técnicos, personales, organizacionales, de comunicación
e interpretación… y valorando su impacto en el desarrollo del proyecto.
Una vez definido o acotado el problema, conviene dedicarle un análisis pausado
viendo la situación en la que surge y las soluciones alternativas posibles para decidir la
respuesta a dar e implementar la solución en el momento adecuado.
Habilidades para negociar y convencer

Negociar no es más que trabajar con otros para llegar a un acuerdo en que ambas
partes ganen. Durante un proyecto, el project manager tendrá que negociar en cada una
de las áreas del proyecto (presupuestos, alcance, recursos…) tanto con personal interno
(miembros del equipo, patrocinador, jefes funcionales…) como externo (proveedores,
clientes, administraciones…).
Convencer implica que la otra parte acepte la solución porque ha llegado a creer
que es la mejor de las posibles, implica conseguir que el equipo haga las tareas tal y como
estaban previstas y requiere por parte del project manager un conocimiento de las
estructuras organizativas formales e informales que están implicadas en un proyecto.
Frente a las habilidades anteriores, el poder implica conseguir que la gente haga cosas
que no haría de otra manera, la capacidad para «hacer cambiar de opinión», cambiar el
rumbo del proyecto e influenciar en los resultados por el rango que ocupa. Imponer, si
el project manager tiene poder, siempre funciona pero debe ser el último recurso.
Habilidades de liderazgo
Los líderes imparten visión, logran consenso en los temas estratégicos, inspiran,
marcan el rumbo y motivan a sus equipos. Los gestores se centran en los resultados, en
cumplir con los requerimientos y las restricciones de base. Los project managers deben
tratar de ser ambas cosas según cuál sea la fase del proyecto y el momento y situación
preciso –en las fases iniciales o cuando haya problemas, aparecerá el líder; cuando el
proyecto vaya bien, predominará el gestor–.
Habilidades para hacer equipo y motivarlo

Los equipos están formados por personas de diferentes áreas de la organización, cada
una con su historia, sus expectativas, que pueden haber trabajado o no juntos antes. El
project manager debe tratar de crear un espíritu de equipo, de trabajo solidario, ayu-
dándoles a trabajar durante las diferentes fases del desarrollo del equipo para lograr que
cada vez sean más autónomos y eficientes y motivarles, especialmente, en proyectos
largos en los que se pierde la referencia, los objetivos se difuminan, cunde el desánimo
y surgen los problemas.
Habilidades para generar confianza

La confianza se asocia con la cooperación, la transparencia y la resolución efectiva
de problemas. Y la confianza es clave para gestionar las expectativas, la implicación y
participación de los interesados del proyecto.
PMBOK propone algunas buenas prácticas para generar confianza como la comu-
nicación abierta y franca para resolver problemas, mantener informados a todos los
interesados del proyecto, mirando más allá de los propios intereses…
Gestión de conflictos
Los conflictos son inevitables en un proyecto y lo peor que puede pasar es que no
afloren (en ocasiones por la falta de confianza que hemos comentado). Los project
manager deben desarrollar habilidades y la experiencia necesaria para afrontar los con-
flictos y resolverlos de forma constructiva y definitiva, buscando la causa raíz de forma
franca y honesta. La resolución de conflictos es una de los mayores retos a los que se
enfrenta el project manager.
Coaching
El coaching implica dialogar con el equipo de proyecto de una forma muy especial
que propicia la motivación y el cambio. Se debe establecer una relación entre las personas
y a partir de ahí dar comienzo un proceso de aprendizaje, así como superación de obs-
táculos, que empieza por la toma de conciencia o diagnóstico de necesidades del grupo.
A continuación se establecerán unos objetivos definidos en un plan de acción que
el equipo se llevará como «tarea». El project manager debe revisar que se cumplen los
objetivos del equipo en relación al proyecto, ajustar los planes de acción… y analizará
los resultados, si los puntos del plan de acción están funcionando o no, si el equipo de
proyecto sigue igual de motivado y comprometido, y qué acciones hay que corregir o
es posible mejorar. Porque el project manager debe desarrollar y gestionar al equipo,
esta habilidad es muy relevante.
62 Introducción
ISO21500 hace una breve referencia a las competencias del personal de proyecto en la que
indica que el personal que trabaje en un proyecto debe desarrollar las competencias en los prin-
cipios y procesos de gestión de proyectos para ser capaz de lograr los objetivos del proyecto.
Divide las competencias en tres categorías:
– Técnicas: para entregar los resultados de los proyectos en una forma estructurada
(incluyen los procesos, conceptos y terminología recogida en la ISO21500).
– De comportamiento: relacionadas con la capacidad de gestionar las relaciones personales
dentro del ámbito del proyecto.
– Contextuales: relacionadas con la gestión de proyecto teniendo en cuenta el entorno
interno y externo a la organización.
1.2.8. Guía del PMBOK®

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edi-
tion, Project Management Institute, Inc., 2017, es el estándar para el project management
de un proyecto y documenta la información necesaria para iniciar, planificar, ejecutar,
monitorizar/controlar y cerrar un proyecto, identifica aquellos procesos de project
management que han sido reconocidos como buenas prácticas en la mayor parte de los
proyectos la mayor parte del tiempo.
Los conocimientos, habilidades y procesos descritos en el PMBOK® Guide, no
deben ser aplicados uniformemente en todos los proyectos. Para cada proyecto, el pro-
ject manager en colaboración con los miembros del equipo de proyecto es responsable
de determinar qué procesos son apropiados y en qué medida. El PMBOK® Guide se
puede aplicar globalmente y a todos los tipos de industria.
El PMI® define otros estándares y modelos acerca del project management como,
por ejemplo el OPM3® que es un modelo de madurez en Dirección de Proyectos que
permite a las organizaciones determinar su nivel de madurez en esta disciplina.
La ISO21500 por su parte indica en la definición de su alcance que es una guía para la
gestión de proyectos, que puede ser utilizada:
– Por cualquier tipo de organización –pública, privada y sin ánimo de lucro–.
– Para cualquier tipo de proyecto, independientemente de su complejidad, tamaño o
duración.
Facilita una descripción somera de conceptos y procesos considerados como buenas prácticas
en gestión de proyectos.
No aborda aspectos relativos a la gestión de carteras de proyectos y/o programas.
En la versión definitiva se eliminó el párrafo que indicaba que «no estaba dirigida a una
certificación» y aunque inicialmente no podrá ser utilizada para certificación o servir de marco
regulatorio, sí es una descripción de alto nivel acerca de cómo desarrollar la gestión de proyectos.
Teniendo en cuenta que las normas ISO son tenidas como los referentes en calidad de
gestión, la ISO21500 podrá llegar sin duda a este nivel.
1.2.9. Grupos de procesos en project management
Qué es un proceso
Los procesos siguen el siguiente esquema: entrada (inputs), técnicas y herramientas
(technics and tools) o salidas (outputs) de un determinado proceso.
Todos los procesos, o al menos buena parte de ellos, estarán encadenados y las salidas
(outputs) de un proceso serán entradas (inputs) de uno o varios procesos y, asimismo,
las entradas (inputs) de un proceso podrán venir de las salidas de uno o varios procesos.
Tipos de procesos
Los procesos pueden ser de gestión de proyectos –cuyo objetivo es lograr los obje-
tivos del proyecto– y los procesos de producto –enfocados a especificar y crear el pro-
ducto del proyecto–. La guía del PMBOK se centra en los primeros.
ISO21500 divide los procesos en tres categorías:

– Procesos de gestión de proyectos: específicos de la gestión de proyectos y que indican
cómo se gestionarán las actividades seleccionadas para dirigir el proyecto concreto.
– Procesos de entrega (similares a los procesos de producto de PMBOK): no exclusivos
de la gestión de proyectos, tienen como resultado la creación de un producto, servicio o

resultado concreto y dependerán del tipo de entregable final del proyecto.
– Procesos de soporte: no exclusivos de la gestión de proyectos, dan apoyo a los dos tipos
de procesos anteriores en aspectos como la logística, control financiero, la seguridad
laboral…
En relación a los procesos de gestión de proyectos, ISO21500 identifica los procesos reco-
mendados para su uso durante la Gestión de Proyectos. Son apropiados para proyectos de
cualquier tipo de organización.
La gestión de proyectos requiere buenas dosis de coordinación y, por ello, cada proceso debe
utilizarse adecuadamente y siempre integrado con el resto de procesos. Los project manager
deben, junto con otras partes interesadas, aplicarlos de la manera más apropiada a las necesidades
de la organización y proyecto. Los project manager deben, por tanto, decidir qué procesos utiliza
y con qué grado de rigor.
64 Introducción
Los procesos de gestión de proyectos

Como se ha comentado anteriormente, la gestión de proyectos consiste en la apli-
cación de habilidades, conocimientos, técnicas y herramientas a las actividades del pro-
yecto para lograr cumplir los requerimientos del proyecto. Esta gestión requiere la apli-
cación y gestión de los procesos más apropiados.
El project manager, en colaboración con el equipo de proyecto, debe determinar
qué procesos son los más adecuados y el grado de detalle y rigor con que se van a ejecutar.
Para que un proyecto tenga garantías de éxito el equipo de proyecto, liderado por
el project manager, debe seleccionar los procesos más apropiados para cumplir los obje-
tivos del proyecto, utilizar una metodología adecuada para lograr cumplir con los
requerimientos, establecer una comunicación continua con las diferentes partes intere-
sadas para gestionar bien sus necesidades y expectativas y lograr su implicación positiva
en el proyecto y equilibrar los intereses de todas ellas sin perder de vista los objetivos
del proyecto, los requerimientos del resultado y las restricciones del proyecto.
Los procesos de Dirección de Proyectos o Project Management organizan y des-
criben el trabajo a realizar para llevar a cabo el proyecto. De acuerdo a PMBOK® Guide
se agrupan en cinco grupos de procesos (inicio, planificación, ejecución, seguimiento
y control y cierre) aunque, como ocurría con las fases, están interrelacionados y depen-
den unos de otros.
ISO21500 los agrupa igualmente en cinco grupos denominados de inicio, de planificación,

de implementación, del control y de cierre.
Esquema general de grupos de procesos

En el esquema siguiente se presentan los cinco grupos de procesos fundamentales y
que se introducirán brevemente a continuación:
Al proceso de avance se le han añadido tres relaciones de retroalimentación (feed-

back):
• Durante la ejecución se supervisan y controlan los avances y se realizan los

cambios necesarios que no necesariamente afecten a la planificación (retroali-
mentación).
• Durante la supervisión, se pueden detectar necesidades de cambios que lleven
a reconsiderar la planificación inicial y actualizar los diferentes planes, general y
subsidiarios (ajustar planificación).
• Durante la supervisión y control se puede llegar a la conclusión de que el pro-
yecto es difícilmente viable (considerar viabilidad):
– Porque hayan cambiado las condiciones del entorno (coyuntura, crédi-
tos…).
– Las desviaciones en coste hasta la fecha lo hacen no rentable.
– O la desaparición de la causa raíz que hizo seleccionar el proyecto.
Grupo de procesos de inicio (Initiating processes)

En este grupo de procesos se reconoce que existe un proyecto fruto de una idea o
una necesidad observada (en proyectos de varias fases se hace oficial que la fase siguiente
pueda iniciarse).
Cuando el Acta de Constitución del proyecto se aprueba el proyecto está oficial-
mente autorizado y el project manager puede comenzar a asignar recursos al proyecto.
Este proceso garantiza la aprobación para comprometer los recursos de la organi-
zación que trabajen en el proyecto o fase y autoriza al project manager a empezar a
trabajar en el proyecto. Los resultados de esta fase son, como veremos posteriormente,
el Acta de Constitución (project charter) y la Lista de Interesados (stakeholders register).
Como parte del proceso de inicio, los proyectos largos y complejos pueden dividirse
en fases. En esos casos, los procesos de inicio se realizarán en cada inicio de fase para
validar las decisiones tomadas en la fase anterior.
Esto ayuda a mantener el proceso centrado en la necesidad de negocio que el pro-
yecto tiene previsto abordar.
66 Introducción
De esta manera se verifican los criterios de éxito, la influencia, objetivos y expec-

tativas de los interesados y se toma la decisión sobre continuar, posponer o suspender
el proyecto.
Los procesos de inicio pueden realizarse, dependiendo de cómo esté definida la
gobernanza de los proyectos, en el ámbito de la gestión de la cartera de proyectos en la
que, para evaluar y priorizar los proyectos, se elabore un caso de negocio previo a el
Acta de Constitución.
El Acta de Constitución deberá reflejar qué porción de la estrategia de negocio va
a resolverse total o parcialmente mediante la ejecución del proyecto a lanzar, de modo
que se defina el vínculo entre el mismo y la estrategia global de negocio marcada por la
dirección.
ISO21500 indica que los procesos del grupo de procesos de inicio son para dar inicio al
proyecto, definir sus objetivos y autorizar al responsable de proyecto a asignar recursos al trabajo.
Grupo de procesos de planificación (Planning processes)

En este grupo de procesos se formulan y revisan los objetivos y metas del proyecto
y se crea un Plan de Dirección del Proyecto para lograr los objetivos propuestos.
Se analizan y definen las diferentes alternativas de actuación y se seleccionan las que
mejor pueden lograr los objetivos establecidos. Asimismo se establecen los requeri-
mientos del proyecto, se afinan los requerimientos del producto y se completa y amplía
la Lista de Partes Interesadas.
Este grupo de procesos es clave ya que en ellos y la documentación generada durante
el propio proceso de planificación se apoyarán buena parte de las actividades y procesos
de fases de ejecución, seguimiento y control y cierre.
En el gráfico adjunto se presentan los procesos de planificación (planning processes)
con las interrelaciones que hay entre ellos:
En ocasiones esta planificación no puede llevarse al nivel deseado para todo el pro-
yecto y desde el inicio del proyecto. En estos casos se va detallando de forma progresiva
conforme avanza el proyecto lo que se denomina «planificación gradual o progresiva»
que subraya el hecho de que la planificación es iterativa y se elabora en un proceso
continuo.
Por todo ello, como se veía en el esquema anterior, la planificación debe englobar
las diez áreas de conocimiento para asegurar que cada una de ellas se considera correc-
tamente en la fase de ejecución. Las áreas de conocimiento y sus objetivos principales
se presentan en la tabla siguiente –aunque se verán con más detalle en el siguiente capí-
tulo–:
Coordinar todos los trabajos para que se realicen correcta-

Gestión de la Integración mente. Tratar de que todo el equipo trabaje alineado hacia los
(Integration Management) mismos objetivos, asegurando que los cambios se revisan, eva-
lúan y aprueban antes de que se apliquen.
Estimar el trabajo que necesita hacerse en el proyecto. Asegu-

Gestión del Alcance (Scope rarse de que nuestro servicio o producto tiene todo lo que se
Management) dijo que tendría y que no tenga nada que no deba tener y que
se ha ejecutado de la manera más eficiente.
68 Introducción
Estimar el tiempo que llevará hacer todo el trabajo y el orden

Gestión del cronograma en que se van a hacer las diferentes actividades. Seguimiento
(Schedule Management) del cronograma tratando de que todos los hitos se cumplan en
plazo.
Saber cuánto hay que invertir en el proyecto, asegurarse que se

Gestión del Coste (Cost
invierte correctamente y que no se producen desviaciones sig-
Management)
nificativas.
Asegurarse que se trabaja tan eficientemente como sea posible

Gestión de la Calidad (Qua- sin cometer errores en el producto y, en caso de producirse, se
lity Management) detecten cuanto antes para que las acciones correctivas y los
impactos sean los menores posibles.
Establecer los recursos necesarios, poniendo al equipo a traba-

Gestión de los Recursos jar, formándole, ayudándole y motivándole. Resolver conflic-
(Resource Management) tos que puedan surgir y reconocer el desempeño al final del
trabajo bien hecho.
Asegurarse de que todas las partes interesadas saben lo que

Gestión de las Comunica- necesitan saber para cumplir su función adecuadamente. Man-
ciones tener informadas a las personas con la información adecuada en
(Communications Manage-
ment) el momento en que lo necesitan para que tomen las mejores
decisiones.
Plantear cómo proteger el proyecto de cualquier evento nega-

Gestión de los Riesgos del
tivo que pueda ocurrir o aprovechar las oportunidades que
Proyecto (Project Risk
surjan y gestionar el riesgo u oportunidad con el Plan de Res-
Management)
puesta previsto, cuando aparezcan.
Encontrar contratistas y proveedores que ayuden a hacer bien

Gestión de las Adquisiciones el trabajo que por falta de capacidad o conocimiento se decide
del Proyecto (Project Pro- subcontratar. Establecer las reglas de funcionamiento a través
curement Management) del contrato y los flujos de comunicación entre comprador y

vendedor.
Identificar los individuos, grupos u organizaciones que tienen

Gestión de las partes intere-
intereses, pueden verse afectados por o tienen que participar en
sadas (Stakeholders mana-
el proyecto, definir sus necesidades y expectativas y planificar
gement)
cómo se va a gestionar su implicación en el proyecto.
ISO21500 indica que los procesos del grupo de procesos de planificación son para detallar
el qué y el cómo se va a ejecutar el proyecto y elaborar las líneas de base contra las que moni-
torizarlo.
Grupo de procesos de ejecución (Execution processes)

Estos procesos implican poner en marcha el Plan de Dirección del Proyecto (Project
Management Plan). En esta fase el project manager coordinará y dirigirá los recursos del
proyecto para lograr los objetivos previstos.
Son los procesos necesarios para completar los trabajos definidos en el Plan de
Dirección del Proyecto para satisfacer las especificaciones de proyecto.
En esta fase se trata de que el proyecto avance al ritmo previsto y asegurar que la
ejecución del proyecto esté alineada con los objetivos del proyecto sin perderlos de vista.
Además en esta fase se producen, revisan y aprueban los cambios, inevitables en todo
proyecto. Es la fase en la que se consumen más tiempo y recursos y en la que los gastos
son más elevados.
En la gráfica siguiente se presentan los procesos implicados y sus interrelaciones:
Es importante recordar que los cambios, inevitables, aparecerán al ir conociendo

más detalles que amplíen el conocimiento del producto y el proyecto. Por ello, el desa-
rrollo del Plan de Dirección del Proyecto y la planificación y la documentación pueden
70 Introducción
plantearse como procesos iterativos y continuos y con detalle creciente, lo que se deno-
mina planificación gradual o progresiva (rolling wave planning or gradual planning).
ISO21500 indica que los procesos del grupo de procesos de implementación son para
realizar las actividades de gestión del proyecto y apoyar la elaboración de los entregables de
proyecto.
Grupo de procesos de seguimiento y control (Monitoring and controlling

processes)
Con este grupo de procesos se toman medidas del avance del proyecto en cada una
de sus vertientes –plazo, coste, trabajo realizado, riesgos...– y se analizan para determinar
si el proyecto se mantiene según lo previsto en el plan base, tratando de identificar los
problemas y desviaciones tan pronto como sea posible y aplicar las acciones correctivas
necesarias para controlar las desviaciones y asegurar el éxito del producto final.
Los posibles cambios o desviaciones nos llevarán a revisar el plan inicial en lo que
se refiere a actividades, recursos, cronograma, presupuestos, riesgos...
72 Introducción
ISO21500 indica que los procesos del grupo de procesos de control son para monitorizar,
medir y controlar el desempeño del proyecto contra el Plan de Proyecto y proponer cambios.
Grupo de procesos de cierre (Closing processes)

Este grupo de procesos trata de completar las actividades del proyecto y cerrarlo
técnica, contractual y administrativamente de manera formal y ordenada aunque, habi-
tualmente, prácticamente sin haber acabado un proyecto, los recursos humanos ya han
sido asignados al siguiente.
Sin embargo, es una fase importante porque toda la información recogida y pro-
ducida durante el cierre del proyecto debe ser revisada y utilizada para detectar errores
y proponer mejoras para futuros proyectos.
El cierre de los contratos con los proveedores y la aceptación formal y aprobación
por parte de las partes interesadas se produce en este momento.
Por ello debemos considerar el cierre correcto una muy buena práctica porque las
lecciones aprendidas y la documentación indexada y archivada del proyecto serán de
gran utilidad para futuros proyectos y project managers.
ISO21500 indica que los procesos del grupo de procesos de cierre son para establecer que
se ha completado el alcance, cumplido los objetivos del proyecto y recoger lecciones aprendidas.
Flujo de grupos de procesos

Como parece lógico todos los grupos de procesos están interrelacionados ya que un
proyecto sufre cambios y esos cambios obligan a revisar elementos de inicio, planifica-
ción, ejecución, y supervisión y control y cierre.
En el esquema siguiente se sintetiza las relaciones entre cada grupo de procesos ya
que cada grupo no es independiente de los demás sino que se produce un proceso general
iterativo.
Por ejemplo, la conclusión de cada grupo de procesos permite al project manager

y los interesados reexaminar sus hipótesis y planificación base y las nuevas necesidades
para determinar si el proyecto está satisfaciendo o no las necesidades del cliente. Y es
una nueva oportunidad para decidir si se sigue adelante o se abandona el proyecto.
ISO21500 indica también las relaciones entre estos grupos de procesos de forma muy
similar, como no podría ser de otra manera, a las definidas en la Guía del PMBOK y pre-
sentadas en el siguiente esquema (Fuente: ISO21500 Guidance on Project Management):
74 Introducción
Flujos de información en el proyecto

Es la relevante distinción entre conceptos relacionados con la información del pro-
yecto, en particular, Datos, Información e Informes:
– Datos de desempeño del trabajo (observaciones y medidas básicas que se realizan
durante la ejecución del proyecto, número de no conformidades…).
– Información de desempeño del trabajo (datos de desempeño recogidos de los
diferentes procesos de control, analizados en su contexto e integrados en base a
las relaciones establecidas entre ellos –estado de avance de los paquetes de tra-
bajo, estimaciones de presupuesto a fin de proyecto…–).
– Informes de desempeño del trabajo (representación física o electrónica de infor-
mación de desempeño del proyecto con el objetivo de que se tomen decisiones
tras su análisis o se transmita un conocimiento a las partes interesadas –informes
mensuales de estado del proyecto…–).
En el siguiente esquema se muestra cómo se relacionan estos tipos de información
de proyecto con los diferentes procesos:
1.2.10. Áreas de conocimiento del Project Management

Como se ha comentado en el apartado anterior, tenemos, de acuerdo a PMBOK®
Guide:
• Por una parte, cinco grupos de procesos que totalizan 49 procesos.
• Y, por otra parte, 10 áreas de conocimiento que debe tener en cuenta el project
manager y que se van desarrollando a lo largo de las fases de avance del proyecto.
Cruzando ambas clasificaciones, y como se refleja en el siguiente esquema, tenemos
procesos para cada grupo y para cada área. En cada área de conocimiento y cada etapa
del proyecto tendremos unos procesos que realizar si bien no todas las áreas de cono-
cimiento tendrán procesos en todos los grupos de procesos.
ISO21500 define también diez áreas de conocimiento –que denomina «grupos temáticos»
(subject groups)– muy similares a las de la Guía del PMBOK: integración, partes interesadas,
alcance, recursos, tiempo, coste, riesgos, calidad, adquisiciones y comunicaciones.
76 Introducción
Gestión de la integración del proyecto (Project integration management)

Esta área de trabajo y conocimiento está relacionada con la coordinación de todos
los aspectos del proyecto. Se puede decir que es el principal trabajo, y el más complejo,
del project manager. Será su día a día. Si desarrollamos el esquema anterior para el caso
de la Gestión de la integración del proyecto (project integration management) nos
encontramos con los siguientes procesos en cada grupo de procesos:
En el grupo de procesos inicial se elabora el Acta de Constitución (project charter)

que incluye identificar y describir en qué consiste el trabajo del proyecto. Asimismo
trata de combinar, unificar e integrar los procesos apropiados. Para ello se hace parale-
lamente –área de gestión de la comunicación– una identificación de las partes interesadas
(identify stakeholders) para que participen en su elaboración.
En el grupo de procesos de planificación se elabora el Plan de Dirección del Proyecto
(Project Management Plan) que es el documento más importante ya que será la guía de
todo lo que va a desarrollarse en el proyecto y abarca todas las áreas de conocimiento.
Da las directrices de cómo manejar los cambios cuando aparecen los problemas.
En el grupo de procesos de ejecución del proyecto el Project manager se encargará
de dirigir la ejecución del proyecto y gestionar el conocimiento del mismo.
Por su parte el seguimiento y control implica anticiparnos a los problemas que
pudieran surgir y abordarlos antes de que sea demasiado tarde. De aquí la necesidad de
establecer indicadores que nos avisen con tiempo si algún elemento se está desviando
más de lo previsto y tener preparados planes de respuesta.
En este mismo grupo de procesos, el control integrado de cambios es muy impor-
tante ya que los cambios se producirán y deberemos estudiar su impacto en las diferentes
restricciones del proyecto para, si procede, aprobarlos conforme a un procedimiento
establecido en el inicio del proyecto (project initiation) garantizando su coherencia con
los objetivos del proyecto.
Esta área de conocimiento utiliza especialmente el método de Earned Value Mana-
gement (Gestión del Valor Ganado), metodología que trata de integrar el desempeño
en coste, plazo y alcance –que veremos con detalle más adelante–.
Por último en el grupo de cierre, una vez realizado todo el trabajo y cerrados los
contratos se cierra el proyecto o fase del mismo.
Las diferencias y similitudes entre ISO21500 y la Guía del PMBOK 6.ª Edición en lo
que a la gestión de la integración se refiere son las siguientes (en cursiva y entre paréntesis los
procesos tal y como están recogidos en ISO21500):
Inicio Planificación Ejecución Control Cierre

Elaborar el Acta Elaborar el Plan Dirigir y gestio- Monitorizar y Cierre del Pro-
de constitución de Dirección del nar los trabajos controlar los tra- yecto o Fase
Proyecto de proyecto bajos de Pro-
(Elaborar el Acta Gestionar el yecto (Cierre del Pro-
de Constitución) (Elaborar los pla- conocimiento yecto o Fase)
nes de proyecto) del Proyecto (Controlar el tra-
bajo de proyecto) (Recoger Lecciones
(Dirigir el trabajo Aprendidas)
de proyecto) Realizar el con-
trol integrado de
cambios
(Controlar los
cambios)
1. Elaborar el Acta de Constitución

Proceso mediante el cual se elabora un documento que autoriza formalmente el
proyecto y da al project manager poder para asignar recursos de la organización a las
actividades del proyecto.
No existen diferencias relevantes sustanciales entre PMBOK 6.ª Edición e ISO21500.
2. Elaborar el Plan de Dirección del Proyecto

Proceso en el que se definen, preparan y coordinan todos los Planes Subsidiarios
para integrarlos en un plan general para la dirección del proyecto.

Cambia la denominación del proceso. Los planes de proyecto (ISO21500) hacen referencia
al Plan de Proyecto y el Plan de Dirección del Proyecto que pueden estar integrados en un único
documento. El Plan de Dirección recoge los planes de gestión de cada área de conocimiento que
definen cómo se va a gestionar el proyecto. Los planes de proyecto recogen las líneas de base de
alcance, tiempo, coste, calidad, recursos y riesgos.
3. Dirigir y gestionar el trabajo del proyecto

Proceso en el que realiza el trabajo definido como necesario en el Plan de Direc-
ción para cumplir los objetivos del proyecto.
No existen diferencias relevantes sustanciales entre PMBOK 6.ª Edición e ISO21500
salvo la diferencia en la denominación del proceso.
78 Introducción
4. Gestionar el conocimiento de proyecto

Es el proceso por el que se crea conocimiento durante el proyecto y se utiliza el
conocimiento adquirido en proyectos anteriores. Es uno de los nuevos procesos que
se incluyen en PMBOK6.
En ISO21500 existe el proceso. Recoger lecciones aprendidas, que aparece en el grupo de
procesos de cierre como se indica más adelante
5. Controlar y monitorizar el trabajo de proyecto

Proceso en el que sigue, revisa y regula el progreso de los trabajos para cumplir
los objetivos de desempeño definidos en el Plan de Dirección del Proyecto.
6. Realizar el control integrado de cambios

Proceso en el que las modificaciones a documentos, entregables o líneas de base
asociadas con el proyecto se identifican, documentan, evalúan y se aprueban o recha-
zan.
7. Cerrar el proyecto o fase

Proceso por el que se finalizan todas las actividades para completar formalmente
el proyecto o fase.
No existen diferencias relevantes sustanciales entre PMBOK 6.ª Edición e ISO21500.
8. Recoger lecciones aprendidas

Este proceso aparece en la ISO21500. Si bien una de las actividades del proceso de Cierre
de Proyecto o Fase en PMBOK 6.ª Edición es la de recoger las lecciones aprendidas (durante
y al final del proyecto), la ISO21500 resalta su importancia creando un nuevo proceso.
El objetivo del proceso es evaluar el proyecto y recoger experiencias que puedan mejorar la
gestión de futuros proyectos. Durante la vida del proyecto, tanto el project manager como el resto
de partes interesadas identifican lecciones aprendidas tanto relativas a aspectos técnicos como de
gestión y organización.
Las lecciones aprendidas deben capturarse, recogerse, formalizarse, archivarse, distribuirse
y utilizarse en este y en futuros proyectos. Estas lecciones aprendidas serán, por tanto, entradas
para buena parte de los procesos de gestión del proyecto.
Gestión del Alcance del proyecto (Project scope management)

En el grupo de procesos de esta área de conocimiento se definen todos los trabajos
y actividades a realizar y sólo los trabajos a realizar. Lo que aparece en la Estructura de
Desglose del Trabajo (EDT) está en el alcance y hay que realizarlo. Lo que no está, no
está en el alcance, el cliente no lo va a pagar y no se hace. Estos procesos se repiten
varias veces a lo largo de la vida del proyecto si se produce, por ejemplo, un cambio en
el alcance (scope change) inicial.
En la fase de planificación se definen y detallan los entregables y los requerimientos

del producto o servicio, se crea el Plan de Gestión del Alcance (Scope Management
Plan) y se crea la Estructura de Desglose de Trabajo (EDT).
En la fase de seguimiento y control se comprueba que los entregables cumplen las
condiciones establecidas, se controlan los cambios en estos procesos y se solicita la apro-
bación parcial de documentos por parte del cliente –validar el alcance (validate scope)–.
Esta área engloba tanto el alcance del producto (product scope) como el del proyecto
(project scope):
• El alcance del producto se refiere a las características del servicio, producto o

resultado del proyecto. Su éxito se mide en función del grado de cumplimiento
de los requerimientos del producto establecidos por el cliente.
• El Alcance del proyecto se refiere a la gestión de las tareas a realizar durante el
proceso. En este caso, el control se hace con el Plan de Dirección del Proyecto,
el documento de requisitos del proyecto, la EDT y el Diccionario de la EDT
que se verán posteriormente.
que a la gestión del alcance se refiere son las siguientes (en cursiva y entre paréntesis los procesos
tal y como están recogidos en ISO21500):
80 Introducción

Planificar la ges- Controlar el
tión del alcance alcance
Recoger requi- Validar el
sitos alcance
Definir el (Controlar el
alcance alcance)
Crear la EDT
(Definir el alcance)
(Crear la EDT)
(Definir activida-
des)
1. Planificar la gestión del alcance

Proceso mediante el cual se documenta cómo se va a definir el Alcance del pro-
yecto, cómo va a ser controlado y cómo va a ser validado durante la ejecución del
mismo.
No existe este proceso en ISO21500 (se considera que se elabora al preparar el Plan de
Dirección del Proyecto y sus Planes Subsidiarios).
2. Recopilar requisitos
Proceso por el cual se identifican y documentan los requisitos derivados de las
necesidades y expectativas de las partes interesadas que son necesarios para cumplir
No existe este proceso en ISO21500 ya que Recopilar Requisitos se incluye en Definir
el Alcance.
3. Definir el alcance
Proceso por el cual se elabora una descripción detallada del proyecto y del pro-
ducto.
En ISO21500 este proceso incorpora al de Recoger Requisitos de PMBOK 6.ª Edición.
4. Elaborar la Estructura de Desglose del Trabajo, EDT
Proceso por el que se subdivide el Alcance del proyecto y sus entregables en
componentes más pequeños y manejables.
No existen diferencias relevantes en este proceso entre PMBOK 6.ª Edición e ISO21500.
5. Controlar el alcance
Proceso por el que monitoriza y controla el estado del alcance del producto y
del proyecto y se gestionan los cambios en la línea de base del alcance.
No existen diferencias relevantes en este proceso entre PMBOK 6.ª Edición e ISO21500.
6. Validar el alcance
Proceso encaminado a formalizar la aceptación formal por parte del cliente de
los entregables completados.
No existe este proceso como tal en ISO21500.
Gestión del Cronograma del proyecto (Project schedule management)

Como se observa en el esquema siguiente buena parte de los procesos de esta área
se concentran en el grupo de procesos de planificación. La gestión del tiempo del pro-
yecto (project time management) busca inicialmente estimar la duración total del pro-
yecto a través de la duración de cada actividad –función de los recursos asignados– y la
secuencia de su ejecución.
Durante la fase de ejecución el project manager trata de que el proyecto no se desvíe
del plazo previsto y que, si esto ocurre, se tomen las medidas adecuadas para recondu-
cirlo.
Estos procesos se suelen repetir de manera iterativa a lo largo del desarrollo del
proyecto cada vez que se producen cambios o se detectan variaciones respecto a lo
previsto. En ocasiones, cuando los proyectos son poco importantes, se suelen concentrar
los procesos de secuenciar actividades, estimar duraciones de actividades y elaborar del
cronograma en una única actividad.
que a la gestión del tiempo se refiere son las siguientes (en cursiva y entre paréntesis los procesos
82 Introducción

Planificar la gestión del Controlar el
Cronograma Cronograma
Definir las actividades (controlar el Cro-
nograma)
Secuenciar las actividades
Estimar la duración de las

actividades
Elaborar el Cronograma
(secuenciar actividades)
(estimar duración de activida-

des)
(elaborar el Cronograma)
1. Planificar la gestión del Cronograma

Proceso mediante el cual se establece la política, procedimientos y documenta-
ción necesaria para planificar, ejecutar y controlar el cronograma del proyecto.
No existe este proceso en ISO21500 si bien se considera que forma parte de la elaboración
del Plan de Dirección del Proyecto y sus Planes Subsidiarios.
2. Definir actividades
Proceso mediante el cual se definen las acciones específicas que es necesario rea-
lizar para producir los entregables del proyecto.
En ISO21500 este proceso forma parte de los procesos del área de conocimiento de gestión
del alcance pero los objetivos y contenido son iguales.
3. Secuenciar actividades
Proceso mediante el cual se definen y documentan las relaciones entre las acti-
vidades del proyecto.
No existen diferencias relevantes entre ISO21500 y PMBOK 6.ª Edición en lo relativo
a este proceso.
4. Estimar la duración de las actividades

Proceso mediante el cual se estiman el número de períodos de trabajo necesarios
para completar cada actividad con los recursos anteriormente estimados.
a este proceso.
5. Elaborar el cronograma
Proceso mediante el cual se analizan las secuencias de las actividades, sus dura-
ciones, los recursos necesarios y las restricciones para crear el cronograma del pro-
yecto.
a este proceso.
6. Controlar el cronograma
Proceso mediante el cual se monitoriza el estado del proyecto para actualizar el
progreso del proyecto y gestionar cambios en la línea de base del cronograma.
a este proceso.
Gestión de costos del proyecto (Project costs management)

Como se ve en el esquema siguiente, este área define cómo se van a calcular y
monitorizar los costes del proyecto, busca estimar los costos de cada recurso, elaborar
el presupuesto a partir de la agregación de los costes de cada actividad y estar atentos a
que el proyecto se mantenga en presupuesto y no se produzcan sobrecostes que reper-
cutan en la rentabilidad esperada.
que a la gestión de costes se refiere son las siguientes (en cursiva y entre paréntesis los procesos
84 Introducción

Plan de Gestión de Costes Controlar los
costes
Estimar los costes
(Controlar los cos-
Determinar el presupuesto tes)
(Estimar los costes)
(Elaborar el presupuesto)
1. Planificar la gestión de costes

Proceso mediante el cual se establece la política, procedimientos y documenta-
ción necesaria para planificar, gestionar, ejecutar y controlar los costes del proyecto.
No existe este proceso en ISO21500 aunque se considera que se elabora como parte del
Plan de Dirección del Proyecto y sus Planes Subsidiarios.
2. Estimar los costes

Proceso mediante el cual se elabora una aproximación a los recursos económicos
necesarios para completar las actividades o paquetes de trabajo individuales.
a este proceso.
3. Determinar el presupuesto
Proceso mediante el cual se agregan los costes estimados de las actividades o
paquetes de trabajo para establecer una línea de base de coste autorizada.
a este proceso.
4. Controlar los costes

Proceso mediante el cual se monitoriza el estado del proyecto para actualizar los
costes y gestionar los cambios necesarios en la línea de base de coste.
a este proceso.
Gestión de la calidad del proyecto (Project quality management)

Este proceso busca asegurar que el proyecto cumple los requerimientos de calidad
establecidos por el cliente y a cuyo cumplimiento nos hemos comprometido. Este área
se centra no sólo en la calidad del producto final sino en la calidad de los procesos de
gestión y dirección del proyecto.
Estos procesos tratan de planificar, medir y controlar la calidad total del desempeño
de los procesos del proyecto, controlar los resultados y compararlos con los niveles
mínimos de calidad establecidos en el Plan de Calidad que a su vez está relacionado con
el documento de requerimientos del producto.
que a la gestión de la calidad se refiere son las siguientes (en cursiva y entre paréntesis los procesos

Planificar la gestión de Gestionar la calidad Controlar la
la calidad calidad
(Realizar el asegura-
(Planificar la gestión de la miento de la calidad) (Realizar el con-
calidad) trol la calidad)
1. Planificar la gestión de la calidad

Proceso mediante el cual se identifican los requisitos de calidad y los estándares
que deben cumplir el proyecto y sus entregables y se documenta cómo va a asegurarse

de que el proyecto cumple con esos requisitos de calidad.
a este proceso.
2. Gestionar la calidad
Proceso mediante el cual se auditan los procesos y la forma de trabajar para con-
firmar que se están cumpliendo los estándares definidos para lograr que los resultados
finales satisfagan los requisitos de calidad.
a este proceso, salvo las diferencias en la denominación
86 Introducción
3. Realizar el control de calidad

Proceso mediante el cual se monitorizan, registran y evalúan los resultados del
proyecto para confirmar que cumplen todos los requisitos establecidos, poder evaluar
los procesos de trabajo y, si procede, proponer cambios en éstos.
a este proceso salvo las diferencias en la denominación.
Gestión de los recursos del proyecto (Project resources management)

Estos procesos tratan de planificar, medir y controlar la calidad total del desempeño
de los procesos del proyecto, controlar los resultados y compararlos con los niveles
mínimos de calidad establecidos en el Plan de Calidad que a su vez está relacionado con
el documento de requerimientos del producto.
Un aspecto singular de los proyectos es que, al ser temporales, tener un inicio y un

fin, una vez cerrado el proyecto los miembros del equipo se distribuyen por otros pro-
yectos y, al iniciarse un nuevo proyecto, los componentes pueden no haber trabajado
juntos antes. Ni siquiera las partes interesadas serán con toda probabilidad las mismas,
con lo cual la gestión de los recursos del proyecto es tan importante en el project mana-
gement.
que a la gestión de los recursos se refiere son las siguientes (en cursiva y entre paréntesis los
procesos tal y como están recogidos en ISO21500):
(Establecer el Planificar la gestión Adquirir el equipo Controlar los

equipo de pro- de los recursos de Proyecto recursos
yecto) (Controlar los
Estimar los recursos Desarrollar el recursos)
equipo de Proyecto
(Estimar los recursos) (Gestionar el
(Desarrollar el equipo equipo de proyecto)
(Definir la organiza- de proyecto)
ción del proyecto)
Dirigir el equipo de
proyecto
Este proceso tiene por objetivo adquirir los recursos necesarios para completar el proyecto.
En PMBOK 6.ª Edición, este proceso aparece en el grupo de procesos de ejecución mientras
que en ISO21500 se recoge en el grupo de procesos de inicio.
En el caso de ISO21500 en este proceso el project manager debe determinar qué recursos,
cuándo y cómo va a ser necesario adquirir mientras que en el proceso Adquirir el Equipo de
PMBOK 6.ª Edición, se refiere a adquirir el equipo definitivo).
1. Planificar la gestión de los recursos del proyecto

Proceso mediante el cual se identifican y documentan los roles, responsabilidades,
habilidades requeridas y flujos de reporte del proyecto así como el Plan de Gestión
del Personal.
2. Estimar los recursos de proyecto

Este proceso tiene por objetivo determinar los recursos (personas, equipamiento,
instalaciones…) necesarios para completar cada actividad. En PMBOK 6.ª Edición
existía ya este proceso pero formaba parte del área de conocimiento de gestión del
tiempo. Ahora, en la PMBOK 6.ª Edición se incluye en el área de Gestión de
Recursos.
(Estimar los recursos.
Se realiza tras identificar las actividades y previamente a estimar la duración de las mismas.
No existen diferencias relevantes entre lo indicado en PMBOK 6.ª Edición e ISO21500
Definir la organización del proyecto
Este proceso corresponde básicamente al proceso Planificar los recursos del proyecto de
PMBOK 6.ª Edición. Tiene por objetivo asegurar el compromiso de todas las partes implicadas
en el proyecto. Se definen los roles, responsabilidades y establecen los niveles de autoridad. Se
define el organigrama del proyecto y los flujos de reporte).
3. Adquirir el equipo de proyecto

Proceso mediante el cual se confirman la disponibilidad de recursos humanos y
se obtiene el equipo necesario para completar las asignaciones de proyecto.
88 Introducción
No existe este proceso en ISO21500 en el grupo de procesos de ejecución pero sí en el

grupo de inicio (Establecer el equipo de proyecto) que tiene un carácter más de planificación.
Este proceso en PMBOK 6.ª Edición busca adquirir el equipo definitivo.
4. Desarrollar el equipo de proyecto

Proceso mediante el cual se mejoran las competencias, la interacción del equipo
y el entorno general del equipo para mejorar el desempeño del proyecto.
No existen diferencias relevantes entre lo indicado en PMBOK 6.ª Edición e ISO21500.
5. Gestionar el equipo de proyecto

Proceso mediante el cual se supervisa el desempeño de los miembros del equipo,
se facilita retroalimentación sobre su trabajo, se resuelven incidencias y se gestionan
cambios con el objetivo de mejorar los resultados del proyecto.
No existen diferencias relevantes entre lo indicado en PMBOK 6.ª Edición e ISO21500
salvo el hecho de que en ISO21500 está en el grupo de control y en PMBOK 6.ª Edición en
el grupo de procesos de ejecución.
6. Controlar los recursos

Este proceso, que no existía en versiones anteriores, pero se ha incluido en
PMBOK 6.ª Edición y en ISO21500 tiene por objetivo asegurarse de que los recursos
necesarios para abordar los trabajos del proyecto están disponibles y asignados de tal
manera que puedan cumplirse los requisitos del proyecto.
Por lo tanto, no existen diferencias relevantes entre lo indicado en PMBOK 6ª
Edición e ISO21500
(Controlar recursos.
Este proceso de ISO21500 (que está en el grupo de procesos de control) tiene por objetivo
asegurarse de que los recursos necesarios para abordar los trabajos del proyecto están disponibles
y asignados de tal manera que puedan cumplirse los requisitos del proyecto. Este proceso podría
asimilarse al de Adquirir el equipo de PMBOK 6.ª Edición, pero teniendo en cuenta que en
ISO21500 no solamente se refiere a recursos humanos sino a recursos en general).
Gestión de la comunicación del proyecto (Project communications mana-

gement)
La mala comunicación es una de las razones más importantes de que los proyectos
fracasen. Pero la comunicación es mucho más que el intercambio de información. Los
procesos que se muestran en el esquema siguiente, tienen por objetivo asegurar que toda
la información relevante relacionada con el proyecto –cronogramas, evaluaciones de
riesgos, informes mensuales, actas de reunión, cambios propuestos…– se recojan, docu-
menten, archiven y se pongan a disposición de todas aquellas personas que lo necesiten
(partes interesadas, alta dirección, miembros del equipo…) en el momento en que lo
necesiten. Todo ello para que tomen las decisiones con el mayor conocimiento del
proyecto posible.
Una vez que el proyecto se cierre, toda la información histórica del proyecto debe
estar bien archivada y fácilmente localizable para que pueda ser de utilidad para futuros
proyectos.
que a la gestión de las comunicaciones se refiere son las siguientes (en cursiva y entre paréntesis
los procesos tal y como están recogidos en ISO21500):

Planificar la Gestión Gestionar las Monitorizar las
de las Comunicacio- Comunicaciones comunicaciones
nes
(Distribuir Informa- (Gestionar las comu-
(Planificar las comunica- ción) nicaciones)
ciones)
1. Planificar la gestión de las comunicaciones

Proceso mediante el cual se recogen y analizan la información de proyecto y las
necesidades de información de las partes interesadas para desarrollar las comunica-

ciones más apropiadas para el proyecto.
No existen diferencias relevantes en este proceso entre lo indicado en PMBOK 6.ª Edición
e ISO21500.
2. Gestionar las comunicaciones:

Proceso mediante el cual se recoge información de proyecto para llevar a cabo,
elaborar, distribuir y archivar las comunicaciones de acuerdo lo establecido en el Plan
de Gestión de las Comunicaciones.
e ISO21500 salvo la diferente denominación del proceso.
90 Introducción
3. Monitorizar las comunicaciones:

Proceso mediante el cual se monitorizan y controlan las comunicaciones a lo
largo de todo el ciclo de vida del proyecto para asegurar que las necesidades de
información de las partes interesadas del proyecto se satisfacen.
e ISO21500 salvo la diferente denominación del proceso.
Gestión de riesgos en el proyecto (Project risk management)

Cuando hablamos de riesgos no debemos pensar solamente en riesgos negativos sino
también en «riesgos positivos» u oportunidades que pueden surgir y hacer que nuestro
proyecto pueda obtener mejores resultados de los previstos.
En el esquema siguiente se observa cómo en la fase de planificación se identifican
los riesgos, evalúan cualitativa y cuantitativamente en relación a la probabilidad de ocu-
rrencia y el impacto sobre el proyecto y, una vez priorizados por estos criterios, se
elaboran un Plan de Seguimiento –con indicadores de ocurrencia– y un Plan de Res-
puesta para cuando ocurran.
En el caso de las oportunidades, siguiendo un método similar acabaremos prepa-

rando un Plan de Seguimiento y respuesta que nos permita aprovecharlas al máximo si
aparecen.
que a la gestión de los riesgos se refiere son las siguientes (en cursiva y entre paréntesis los procesos

Planificar la gestión de Implementar la Monitorizar los
riesgos respuesta a los riesgos
riesgos
Identificar los riesgos (Controlar los riesgos)
(Tratar los riesgos)
Realizar el análisis cuali-
tativo de riesgos
Realizar el análisis cuan-

titativo de riesgos
Planificar la respuesta a los

riesgos
(Identificar riesgos)
(Evaluar los riesgos)
1. Planificar la gestión de riesgos del proyecto

Proceso mediante el cual se define cómo se va a realizar las actividades encami-
nadas a gestionar los riesgos del proyecto.
Este proceso no se recoge en ISO21500 si bien se considera que se elabora como parte del
Plan de Dirección del Proyecto y sus Planes Subsidiarios.
2. Identificar los riesgos

Proceso mediante el cual se determinan qué riesgos y oportunidades pueden
afectar al proyecto y documentar sus características.
Este proceso no se diferencia del que recoge la ISO21500.
3. Realizar el análisis cualitativo de los riesgos

Proceso mediante el cual se priorizan los riesgos mediante la evaluación conjunta
de su probabilidad e impacto con el objetivo de identificar aquellos que requerirán

un análisis más detallado.
ISO21500 recoge el proceso «Evaluar riesgos» cuyo objetivo es medir y priorizar los riesgos
identificados. Por tanto recogería los objetivos y contenidos de los procesos «Realizar el análisis
cualitativo de riesgos» y «Realizar el análisis cuantitativo» de riesgos de PMBOK 6.ª Edición.
4. Realizar el análisis cuantitativo de los riesgos

Proceso mediante el cual se analiza el impacto numérico del efecto de los riesgos
identificados como más relevantes en los objetivos del proyecto.
Como se ha indicado ISO21500 recoge en el proceso «Evaluar riesgos» los objetivos y
contenidos de los procesos «Realizar el análisis cualitativo de riesgos» y «Realizar el análisis
cuantitativo» de riesgos de PMBOK 6.ª Edición.
92 Introducción
5. Planificar la respuesta a los riesgos

Proceso mediante el cual se estudian opciones y se definen acciones para aumen-
tar la probabilidad e impacto de las oportunidades y reducir la probabilidad e impacto
de los riesgos.
El proceso «Tratar los riesgos» de ISO21500 recoge los objetivos y contenidos del proceso
«Planificar la respuesta a los riesgos» de PMBOK 6.ª Edición sin diferencias significativas salvo
el hecho de que en ISO21500 el proceso forma parte del grupo de procesos de ejecución y en
PMBOK 6.ª Edición del grupo de procesos de Ejecución.
6. Implementar la respuesta a los riesgos

Proceso mediante el cual se ponen en marcha los planes de respuesta definidos.
El proceso «Tratar los riesgos» de ISO21500 recoge los objetivos y contenidos del proceso
«Implementar la respuesta a los riesgos» de PMBOK 6.ª Edición sin diferencias significativas.
7. Monitorizar riesgos
Proceso mediante el cual se implementan los planes de respuesta a riesgos, se
monitorizan los riesgos identificados y los residuales, se identifican nuevos riesgos y
se evalúa la efectividad de la gestión de riesgos durante la vida del proyecto.
El proceso Controlar riesgos de ISO21500 recoge los objetivos y contenidos que el proceso
del mismo nombre de PMBOK 6.ª Edición.
Gestión de adquisiciones del proyecto (Project procurement management)

En estos procesos se definen los procedimientos de compras de productos, servicios,
materiales, equipamientos a vendedores, contratistas, consultores, proveedores… de los
servicios y elementos que no hará el equipo de proyecto. En estos procesos el project
manager asume la posición de comprador, a diferencia del caso del proyecto general en
el que es vendedor para un cliente.
que a la gestión de las adquisiciones se refiere son las siguientes (en cursiva y entre paréntesis

Planificar la gestión de Efectuar las Controlar las
adquisiciones adquisiciones adquisiciones
(Planificar las adquisicio- (Seleccionar provee- (Gestionar las

nes) dores) adquisiciones)
1. Planificar la gestión de adquisiciones

Proceso mediante el cual se documentan las decisiones de compras del proyecto
especificando el método e identificando los potenciales proveedores.
El proceso «Planificar las adquisiciones» de ISO21500 recoge los mismo objetivos y con-
tenidos.
2. Efectuar las adquisiciones

Proceso mediante el cual se obtienen las respuestas de potenciales proveedores,
se selecciona el proveedor y se firma el contrato.
El proceso Seleccionar proveedores de ISO21500 recoge los mismo objetivos y contenidos
que el proceso «Efectuar las adquisiciones» de PMBOK 6.ª Edición.
3. Controlar las adquisiciones

Proceso mediante el cual se gestionan las relaciones del contrato de adquisiciones,
se monitoriza el desempeño del contrato y se realizan cambios y correcciones si fuera
necesario.
El proceso «Gestionar las adquisiciones» de ISO21500 recoge los mismo objetivos y con-
tenidos que el proceso Controlar las adquisiciones de PMBOK 6.ª Edición.
4. Cierre de las adquisiciones

Proceso mediante el cual se completa y cierra contractualmente cada adquisición
del proyecto.
No existe este proceso en ISO21500 por lo que se considerará parte del proceso Gestionar
las adquisiciones o del de Cierre de Proyecto.
Gestión de interesados del proyecto (Project Stakeholders management)

En este proceso, se pretende identificar todos los individuos, grupos u organizacio-
nes que tienen algún interés real o percibido en el proyecto, identificar sus necesidades
y expectativas para definir así una estrategia de gestión de las mismas para durante la fase
de ejecución del proyecto controlar y gestionar su implicación en el proyecto.
94 Introducción
que a la gestión de las partes interesadas se refiere son las siguientes (en cursiva y entre paréntesis

Identificar a los Planificar la Gestionar la par- Monitorizar la
interesados involucración ticipación de los involucración de
de los interesa- interesados los interesados
(Identificar a las partes
interesadas) dos (Gestionar a las
partes interesadas)
1. Identificar a los interesados:

Proceso en el que se identifican todas las personas y organizaciones relevantes
afectadas por el proyecto, analizando y documentando información relevante relativa
a sus intereses, implicación, interdependencias e impacto potencial sobre el proyecto.
No existen diferencias sustanciales entre PMBOK 6.ª Edición e ISO21500 salvo la

diferencia en la denominación del proceso.
2. Planificar la involucración de los interesados:

Proceso en el que se desarrollan las estrategias de gestión adecuadas para implicar
de forma efectiva a los stakeholders en las decisiones del proyecto y su ejecución
teniendo en cuenta sus necesidades, expectativas, intereses y potencial impacto sobre
el proyecto.
No existe este proceso en ISO21500, si bien sus contenidos y objetivos se incluyen en el
proceso ISO21500 «Identificar los interesados».
3. Gestionar la participación de los interesados:

Proceso mediante el cual se comunica y trabaja con las partes interesadas durante
la ejecución del proyecto para satisfacer sus necesidades y expectativas, abordar los
problemas conforme ocurran y promover una participación activa y efectiva de las
partes interesadas en las decisiones y ejecución del proyecto.
No existen diferencias sustanciales entre PMBOK 6.ª Edición e ISO21500 salvo la

diferencia en la denominación del proceso.
4. Controlar la involucración de los interesados:

Proceso por el cual se controlan las relaciones de las diferentes partes interesadas
entre sí y con el proyecto y se proponen cambios y ajustes en los planes y estrategias
de gestión de las mismas.
No existe este proceso en ISO21500, si bien sus objetivos y actividades se consideran
incluidas en el proceso «Gestionar los interesados» de ISO21500.
Síntesis final
En la tabla siguiente y siguiendo el esquema general del PMBOK® podemos ver
de forma global las 10 áreas y los 5 grupos de procesos que hemos introducido en este
punto y que permiten tener una visión global de qué procesos poner en marcha y en
qué fases.
Puede utilizarse como una lista de control a tener presente en todo el proyecto ya
que nos indicará los procesos que se deben considerar aplicar en cada momento.
96 Introducción
2.
Inicio del proyecto
El Inicio es el pistoletazo que da lugar al proyecto, reconociendo que proyecto o

fase siguiente del proyecto es una realidad y que culmina con el Acta de Constitución
(project charter) del proyecto y la Lista de Interesados (stakeholders register).
En este grupo de procesos comienzan a aplicarse dos áreas de conocimiento:
• La gestión de la integración del proyecto, con el proceso «Desarrollar al Acta de
Constitución (Develop the Project Charter)».
• El área de conocimiento de gestión de las partes interesadas, con el proceso
«Identificar a los interesados (Identify stakeholders)».
El siguiente esquema sintetiza la fase de inicio:
98 Inicio del proyecto
Las actividades del grupo de Inicio (Mulcahy, 2011) son las siguientes:
• Seleccionar el project manager.
• Determinar la cultura de la compañía y los sistemas existentes.
• Revisar procesos, procedimientos e información histórica.
• Dividir el proyecto en fases.
• Documentar el Caso de Negocio.

• Determinar los objetivos del proyecto.
• Elaborar el Acta de Constitución.
• Identificar las partes interesadas (stakeholders).
En ISO21500 se proponen tres procesos en el grupo de procesos de inicio: desarrollar el

Acta de Constitución, identificar los interesados y establecer el equipo de proyecto; que corres-
ponden, por este orden, a las áreas temáticas (las áreas de conocimiento según ISO21500) de
gestión de la integración, gestión de las partes interesadas y gestión de los recursos.
2.1. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO
De acuerdo con Project Management Institute, A Guide to the Project Management Body
of Knowledge (PMBOK® Guide) – Sixth Edition, Project Management Institute, Inc.,
Gestión de la integración del proyecto 99
20171, la gestión de la integración del proyecto (project integration management)

incluye los procesos y actividades necesarias para identificar, definir, combinar, unificar
y coordinar los diversos procesos y actividades de la dirección del proyecto. Ello implica:
• Tomar decisiones en cuanto a la asignación de recursos.
• Equilibrar los objetivos y alternativas e intereses contrapuestos.
• Manejar las interdependencias entre las áreas de conocimiento.
Este proceso trata de particularizar las buenas prácticas del PMBOK® Guide al pro-
yecto concreto. Es importante subrayar que la percepción de que un proceso no es
necesario no significa que no deba ser, al menos, considerado. El project manager y su
equipo deben abordar cada proceso y determinar si procede aplicarlo en el proyecto
concreto y el nivel de detalle y rigor con que se va a tratar cada uno.
El project manager trata de que los proyectos se desarrollen adecuadamente y sin
sobresaltos para lo cual debe planificar lo que va a ocurrir en el proyecto. Buena parte
de su trabajo será:
• Vigilar estrechamente el avance real del proyecto para asegurarse que el plan
previsto se cumple.
• Cuando las cosas empiezan a ir mal, tomar las medidas oportunas para resolver
los problemas y encauzar el proyecto a tiempo.
Como los problemas, los cambios, los imprevistos forman parte del día a día de un
proyecto, los project managers deben identificarlos con antelación, si es posible, y tratar
de solucionarlos cuanto antes.
La gestión de la Integración del Proyecto es el trabajo del día a día del project
manager. Su razón de ser es llevar a cabo la gestión integrada del proyecto para ensamblar
y mantener todas las piezas –Planes Subsidiarios del resto de áreas de conocimiento– de
un proyecto como un todo coherente y coordinado buscando el equilibrio entre ellas
y que no sean planes independientes sino perfectamente interrelacionados.
Como se representa en el esquema siguiente es la única área de conocimiento que
aparece en todos los grupos de procesos (inicio, planificación, ejecución, seguimiento

y control y cierre):
1. PMBOK es una marca registrada del Project Management Institute, Inc.
Como se ha indicado, todos los proyectos, sean más o menos complejos, siguen un
patrón similar: primero se inician, luego se planifican, a continuación se ejecutan, se
supervisan y controlan, y finalmente se cierran. Si el proyecto es complejo y se divide

en fases este ciclo se repetirá para cada fase y el cierre de una fase llevará (si procede) al
inicio de la siguiente. Y, por lo tanto, el trabajo del project manager se esquematiza en
el siguiente esquema:
Los procesos para la gestión integrada del proyecto son los seis que se presentan en
el siguiente esquema:
Como vimos en el capítulo anterior existen algunas diferencias entre los procesos de la Guía
del PMBOK y la ISO21500 en lo que a gestión de la integración se refiere. En el siguiente
cuadro se reflejan los procesos de PMBOK y los de ISO21500 (estos últimos en cursiva).

Desarrollar el Elaborar el Plan de Dirigir y gestio- Monitorizar y con- Cerrar el Pro-
Acta de Cons- Dirección del nar los trabajos trolar los trabajos yecto o Fase
titución Proyecto de proyecto de Proyecto (Cierre del Pro-
(Elaborar el Acta (Elaborar los planes Gestionar el (Controlar el trabajo yecto o Fase)
de Constitución) de proyecto) conocimiento de proyecto) (Recoger Leccio-
del Proyecto Realizar el control nes Aprendidas)
(Dirigir el trabajo integrado de cam-
de proyecto) bios
(Controlar los cam-
bios)
Y se presentan en la siguiente tabla –si bien se tratan con mayor profundidad al

hablar de cada proceso en su fase correspondiente–:
Desarrollo del Acta de Constitución (Develop the project charter)

No sería posible empezar a planificar la gestión sin una idea del tipo de trabajo
Inicio que estamos hablando. Elaborar el Acta forma parte de este proceso de inte-
(Initiation) gración de la gestión.
No existen diferencias relevantes sustanciales entre PMBOK 6.ª Edición e

ISO21500.
Desarrollo del Plan de Dirección del Proyecto (Develop the project
management plan)
Este documento es el más importante ya que será la guía de todo lo que va
a desarrollarse en el proyecto y abarca todas las áreas de conocimiento. Buena
parte de este documento da directrices de cómo manejar los cambios cuando
aparecen los problemas. Cuando hay alguna duda sobre cómo abordar una
Planificación situación del proyecto es el documento a consultar.
(Planning)
En ISO21500 cambia la denominación del proceso. Los planes de proyecto de la
ISO21500 hacen referencia al Plan de Proyecto y el Plan de Dirección del Proyecto
que pueden estar integrados en un único documento. El Plan de Dirección recoge los
planes de gestión de cada área de conocimiento que definen cómo se va a gestionar el
proyecto. Los planes de proyecto recogen las líneas de base de alcance, tiempo, coste,
calidad, recursos y riesgos.
Gestionar el conocimiento del proyecto (Manage Project know-
ledge)
Durante la ejecución del proyecto debe realizarse una doble labor relacio-
nada con el conocimiento. Por un lado será necesario coordinar adecuada-
Ejecución mente el uso del conocimiento existente para aprovecharlo en el proyecto
(Execution) actual. Por otro lado, deberá recopilarse el nuevo conocimiento generado
para poder ser aprovechado no solo en el proyecto en ejecución, sino tam-
bién en proyectos futuros, mediante el archivado en los activos de la orga-
nización.
Monitorizar y controlar el trabajo del proyecto (Monitor and con-
trol project Work)
Paralelamente a la ejecución del proyecto, el project manager ejecuta las

actividades de revisión, medición y supervisión continua y reporta periódi-
camente si el proyecto va de acuerdo a lo previsto o no y si aparecen nuevos
Supervisión y riesgos u oportunidades.
control
(Monitoring Asimismo detecta los problemas tan pronto como sea posible, evaluando su
and control) impacto y proponiendo soluciones. Cuanto más tarde se detecte un pro-
blema, más difícil y cara será su solución.
ISO21500 salvo la diferencia en la denominación del proceso (en ISO21500 se
denomina Controlar el trabajo de Proyecto –Control Project Work–).
Realizar el control integrado de cambios (Perform Integrated
Change Control)
Cuando se detectan problemas en el desarrollo del proyecto, el project
Supervisión y manager debe trabajar conjuntamente con su equipo de trabajo y las partes
control interesadas y el patrocinador (sponsor) para ver cómo manejarlos y poner en
(Monitoring marcha la solución más adecuada.
and control) También debe actualizar el Plan de Dirección para reflejar las nuevas acti-
vidades o pasos a dar fruto de los cambios, problemas, incidencias surgidas.
Y actualizar el plan inicial y distribuirlo a todas las personas interesadas ase-
gurando que todas las partes están al día, lo que facilitará el trabajo y evitará
malentendidos y errores.

ISO21500 salvo la diferencia en la denominación del proceso (en ISO21500 se
denomina Controlar los Cambios –Control Changes–).
Cierre del proyecto o fase (Close project or phase)
La última tarea del proyecto es, una vez completado el proyecto y cerrados
todos los contratos (close procurements), proceder al cierre administrativo
del proyecto (close Project or phase) así como asegurarse de que queda todo
Cierre documentado y que se han identificado y distribuido las lecciones aprendi-
(Closing) das.

ISO21500.
(En ISO21500) Recoger Lecciones aprendidas (Collect Lessons
Learned)
Este proceso aparece en la ISO21500. Si bien una de las actividades del proceso de
Cierre de Proyecto o Fase en PMBOK 6.ª Edición es la de recoger las lecciones
aprendidas (durante y al final del proyecto), la ISO21500 resalta su importancia
Cierre creando un nuevo proceso.
(Closing) El objetivo del proceso es evaluar el proyecto y recoger experiencias que puedan mejorar
la gestión de futuros proyectos. Las lecciones aprendidas deben capturarse, recogerse,
formalizarse, archivarse, distribuirse y utilizarse en este y en futuros proyectos. Estas
lecciones aprendidas serán, por tanto, entradas para buena parte de los procesos de
gestión del proyecto.
Al inicio de cada uno de los grupos de fases siguientes (planificación, ejecución,

seguimiento y control y cierre) se desarrollarán con más detalle los procesos de gestión
de la integración del proyecto. A continuación nos centramos en el del grupo de pro-
cesos de Inicio del proyecto.
2.1.1. Desarrollar el acta de constitución

Una vez que se ha decidido seguir adelante con el proyecto, comienza el grupo de
procesos de Inicio del proyecto (project initiation) que debe concluir con dos resultados
muy importantes:
• El Acta de Constitución (project charter) del Proyecto.
• La Lista de Interesados (stakeholders register).
Cada uno de los procesos –Elaborar el Acta de Constitución e Identificar los intere-
sadas– tendrán unos datos de entrada (inputs), unas técnicas y herramientas (techniques
and tools) cuya aplicación darán unos resultados (outputs).
El Acta de Constitución es un documento clave ya que vincula el proyecto en
cuestión con la estrategia y los objetivos estratégicos de la organización. Al desarrollar
este proceso se pretende elaborar un documento que:
• Autorice formalmente un proyecto o fase.
• Documente los requisitos iniciales que satisfacen las necesidades y expectativas

de los interesados.
• Nombre y defina la autoridad del project manager.
El proyecto se inicia formalmente con la firma de este documento aprobado.
Cuanto antes se nombre al project manager, mejor. Conviene tenerlo identificado
durante la fase de elaboración de este Acta para que participe en su elaboración. De
hecho es el Acta la que formalmente nombra al project manager y le asigna las funciones
y autoridad pertinentes.
El Acta puede elaborarla quien autoriza el proyecto (comité ejecutivo, oficina de
proyectos, patrocinador…) o el project manager con su colaboración pero debe ser
finalmente aprobada y firmada por el patrocinador (sponsor) quien a su vez será el res-
ponsable de aprobar cualquier cambio que afecte a este documento –que ocurrirá muy
pocas veces ya que si el cambio es muy relevante puede dar lugar a un nuevo proyecto–.
Trata de responder en primera instancia, y a través de los elementos que la consti-
tuyen y que se verán a continuación las siguientes preguntas:
• ¿En qué consiste el proyecto?
• ¿Quién tiene la autoridad para liderar el proyecto y puede determinar, gestionar
y aprobar los cambios en el presupuesto, plazos o alcance?
• ¿Por qué se aborda el proyecto? ¿Existe una justificación de rentabilidad eco-
nómica, de oportunidad de mercado, de estrategia empresarial?
• ¿Qué recursos se van a poner a disposición del proyecto?
• ¿Quién se verá afectado o deberá participar en el proyecto (identificando las
partes interesadas)?
• ¿Qué requerimientos tiene el producto y el proyecto mediante el que se desa-
rrollará el producto?
• ¿Qué documentos, entregables en general, se van a entregar al cliente? ¿Cuál
será el resultado final para el cliente? ¿Qué recibirá como producto o servicio?
• ¿Cómo se integra el proyecto dentro de los objetivos estratégicos de la compa-

ñía? ¿Qué objetivos del proyecto están enfocados a lograr aquellos?
• ¿Qué o quién debe aprobar los requerimientos e hitos del proyecto?
• ¿Qué riesgos generales y preliminares pueden afectar al proyecto y su éxito final?
Siendo el primer documento que se desarrolla, es un documento clave para las fases
posteriores en las que el proyecto y sus actividades se irán desgranando en elementos
más pequeños y para que sean coherentes con el objetivo inicial del proyecto y, muy
especialmente, con la estrategia de la compañía.
Uno de los beneficios clave de este proceso es que da una oportunidad de aprobación
formal del proyecto a la dirección de la organización y clarifica el inicio del proyecto y
el momento en el que se pueden comenzar a asignar recursos.
Este proceso se sitúa dentro del proceso general de gestión de la integración del
proyecto:
Y se sintetiza su contenido en la siguiente figura:
Para ISO21500 es también un documento que autoriza formalmente un proyecto o fase,

nombra al project manager definiendo su poder y responsabilidades, documenta las necesidades
de negocio, objetivos del proyecto, entregables esperados y aspectos económicos del proyecto.
Relaciona los objetivos estratégicos y de negocio de la organización con los objetivos del proyecto.
En la siguiente tabla se indican las entradas y salidas propuestas por ISO21500 (no indica
técnicas ni herramientas):
Entradas Salidas
Enunciado del Alcance del Proyecto Acta de Constitución
Contrato
Caso de negocio
Cabe destacar que, aunque el nombre coincida con la principal salida del proceso de Definir
el Alcance de PMBOK, se refiere al Enunciado del Trabajo del Proyecto (Project Statement
of Work), entrada en PMBOK para elaborar el Acta de Constitución.
DESARROLLAR EL ACTA DE CONSTITUCIÓN (DEVELOP PRO-

JECT CHARTER):
El Acta de Constitución (project charter), resultado del proceso de «Desarrollo
del Acta de Constitución del Proyecto (Develop Project Charter)», es la confirmación
escrita de que el proyecto existe y se puede empezar a trabajar en él. Nombra al
Project Manager y le da autoridad para asignar recursos de la organización al proyecto.
Además es el documento que se utiliza para informar a toda la compañía porqué el
proyecto es necesario y qué se espera de él.
Aunque sea lo deseable, en ocasiones el project manager no está implicado en su
elaboración sino que es el patrocinador (sponsor), que a veces coincide con la figura de
cliente, quien la elabora y entrega firmada al project manager.
Sin este documento el project manager no tiene autoridad para decir al equipo de
proyecto qué hacer y cuándo hacerlo ni puede comenzar a dedicar horas ni asignar
recursos al mismo.
ENTRADAS (INPUTS):
Entre la información necesaria para elaborar el Acta de Constitución están:
• Documentos de negocio, que deberán ser revisados periódicamente puesto que
han sido elaborados previamente al inicio del proyecto. Caben destacar:
– El caso de negocio –donde se justifica la razón de negocio para lanzar el
proyecto ya sea una demanda de mercado, una necesidad de la organiza-
ción, una solicitud de un cliente, un avance tecnológico, un requerimiento
legal… –.
– El plan de gestión de beneficios –que refleja los principales beneficios
esperados tras la ejecución del proyecto.
• Un contrato con un cliente.

• Los factores ambientales de la organización.
• Y los activos de los procesos de la organización –entre estos últimos,
las políticas y procesos de la organización, las plantillas e información
histórica y lecciones aprendidas de proyectos anteriores–.
Documentos de negocio (Business documents)

Compuesto principalmente por el plan de gestión de beneficios y el caso de negocio.
Caso de negocio (Business case)

El caso de negocio se creará como resultado de una demanda del mercado (un nueva
aplicación para móviles), una necesidad de la organización (la implantación de un pro-
ceso de calidad 6 Sigma),una solicitud de un cliente (una mejora sustancial en la maqui-
naria instalada), avances tecnológicos (una nueva aplicación para la nueva generación
de tablets), requerimientos legales (el cumplimiento de la nueva ley de protección de
datos por parte de los sistemas de una entidad bancaria) o por otras razones.
Ahora el objetivo es explicar por qué y cómo atiende el proyecto las necesidades de
negocio y dejar claro que la inversión en el proyecto merece la pena.
Preparar un caso de estudio lleva a reflexionar sobre el valor del proyecto para
nuestro negocio, si hay un mercado suficiente, si hay que hacerlo porque el cliente así
lo ha pedido, si generará sinergias con otras áreas de la empresa…
Si el proyecto:
• tiene demasiado riesgo;
• y/o no va a ser muy rentable;
• y/o no está alineado con la estrategia del grupo;
• y/o hay serias dudas de que vaya a salir adelante;
la alta dirección no lo lanzará. Para valorar su rentabilidad se utilizarán los parámetros
introducidos en el punto 1.2 y explicados con más detalle en el 8.3 «Dirección Estra-
tégica por Proyectos» y 8.1 «Financiación del proyecto».
Es responsabilidad del project manager conocer por qué y para qué se ha seleccio-
nado el proyecto y cómo encaja en el plan estratégico de la organización y tratar de
lograr que el proyecto satisfaga esas necesidades. Lo deberá tener muy en cuenta a la
hora de evaluar el impacto de los cambios que se propongan en la fase de ejecución.
Su contenido normalmente suele ser el siguiente:
a) Necesidades de negocio
• Determinación de la motivación que impulsa la acción.
• Declaración situacional que describa el problema o la oportunidad de negocio
a abordar.
• Valor que aporta a la organización.
• Identificación de los interesados afectados.
• Breve descripción del alcance.

b) Análisis estratégico de la situación que tratará de responder a los cuatro
aspectos anteriores y muy especialmente hacer una estimación cuantitativa
de la rentabilidad esperada, del volumen de beneficios…
• Identificación de estrategias, metas y objetivos que persigue la organización con
el proyecto.
• Identificación de las causas raíz del problema o de los principales contribuyentes
de una oportunidad, según sea el caso.
• Riesgos identificados.
• Principales factores de éxito.
• Identificación de criterios de decisión (requeridos, deseados, opcionales)
• Consideraciones –que pueden ser descritas a modo de escenario empresarial- a
tener en cuenta para alcanzar el objetivo de negocio.
c) Recomendación
• Descripción de la opción recomendada para el proyecto. Dicha descripción
contendrá al menos: los resultados del análisis para la opción recomendada,
limitaciones, asunciones, riesgos y dependencias y mediciones de éxito (criterios
de aceptación).
• Adicionalmente se puede acompañar de un enfoque de la implementación que
contendría básicamente: hitos, dependencias y roles y responsabilidades.
• Los proyectos relacionados y con los que puede ser complementario, generar
sinergias o en los que se puede fijar para abordarlo y realizar una buena plani-
ficación inicial. Incluso ver si, aunque en este proyecto no se gane nada, pueda
haber proyectos que se beneficien de sus resultados.
d) Evaluación que describirá cómo se va a medir el proyecto con respecto
a los beneficios esperados.
Si tras analizar la documentación del proyecto el project manager considera que el
presupuesto aprobado es una limitación que puede impedir el éxito del proyecto y
alcanzar los objetivos de la empresa, debe hacerlo saber y solicitar un aumento del mismo
ya que, de otra manera, el proyecto fracasará y el compañía no alcanzará sus objetivos
–y la responsabilidad del fracaso será del project manager–.
Es responsabilidad del project manager no aceptar un proyecto siendo consciente
que, tal y como está planteado, no va a cumplir sus objetivos.
En el caso de proyectos con fases múltiples, este caso de negocio debe ser revisado
periódicamente, preferentemente al final de cada fase y previo al inicio de la siguiente
para ver si las condiciones que dieron lugar a su viabilidad o rentabilidad se mantienen
o no y, dependiendo del resultado, avanzar o no con la siguiente fase.
Acuerdos y contratos (Agreements)

Pueden tomar la forma de un contrato o un Memorandum, un acuerdo verbal o
escrito… Procederá considerarlo como entrada cuando la organización en la que tra-

bajamos está desarrollando un proyecto para un cliente externo. Es una entrada a este
proceso ya que documenta las condiciones en las que el proyecto debe ejecutarse.
Factores ambientales de la empresa (Enterprise environmental factors)

En este punto se debe hacer referencia a elementos externos al proyecto que pueden
tener una influencia relevante sobre él y que el project manager debe tener bien en
cuenta a la hora de comenzar a lanzarlo como:
• La cultura de empresa, su estructura organizativa y sus procesos de funciona-
miento.
• La legislación y estándares normativos de las administraciones públicas en mate-
ria de seguridad laboral alimentaria, medio ambiente, calidad…
• La infraestructura de la empresa: equipamiento, instalaciones, oficinas…
• Los recursos humanos: la plantilla existente, sus aptitudes, conocimientos y

habilidades.
• El departamento de recursos humanos: con sus criterios y procedimientos de
contratación, desvinculación, formación, evaluaciones del desempeño y remu-
neración.
• El sistema de autorización de trabajos (work authorization system) en la orga-
nización: cómo se autorizan las contrataciones, las solicitudes de trabajos, cómo
se asignan las tareas a los equipos y se asegura que son realizadas adecuadamente
y en el orden establecido.
• Las condiciones del mercado: la clásica teoría de la oferta-demanda con los fac-
tores económicos y financieros.
• Las tolerancias al riesgo de las partes interesadas, esto es, el riesgo que están
dispuestos a aceptar teniendo en cuenta los ratios de rentabilidad del proyecto.
• El clima político interno y externo y su influencia en el proyecto o la organi-
zación.
• Los canales de comunicación establecidos en la organización para comunicarse
tanto interna como externamente, la cadena de mando, los flujos de reporte…
• Otros aspectos como las bases comerciales que se tengan con información del
sector en el que se desarrolla el proyecto.
Activos de los procesos de organización (Organizational process assets)
En este punto, el project manager debe fijarse en las políticas, recomendaciones,
buenas prácticas, procedimientos, planes y estándares que la organización tiene implan-
tados. Y muy especialmente los que afecten al trabajo en el proyecto:
• Políticas de Dirección de Proyectos.
• Políticas de seguridad.
• Criterios de evaluación del desempeño.
• Plantillas para controles económicos y de avance.
• Requisitos de información.
• Procedimientos de control de cambios (change control procedures)…
Esta información se divide en Procesos y procedimientos y Conocimiento corpo-
rativo como se vio en el punto 1.2.4 «Condicionantes de un proyecto».
También incluyen la información que la organización tiene de proyectos anteriores
como:
• riesgos en proyectos anteriores,
• medidas de desempeño,
• plazos de esos proyectos,
• datos del Valor Ganado (earned value data),
que conocemos como información histórica (historical information) y que forma
parte de conocimiento corporativo básico.
Esta información tan útil estará accesible si los anteriores project managers han
recogido, archivado y guardado toda esa información –datos financieros, lecciones
aprendidas, ficheros de proyectos…–. Por ello, como buenos project managers, debe-
remos actuar de igual manera.
Toda esta información debe ser revisada y evaluada al inicio de un proyecto porque
puede llegar a darnos información que nos haga cambiar de opinión sobre la viabilidad
u oportunidad del proyecto. Además ayudará a desarrollar el Acta de Constitución del
proyecto (Develop Project Charter), la definición y la estimación de actividades en la
fase de planificación.
Todo esto muestra la importancia de que se guarde y actualice un registro histórico
de lo que ocurre en cada proyecto y que, al final del proyecto, el project manager se
reúna con su equipo y, a ser posible, el resto de las partes interesadas y pongan por escrito
lo que ha salido bien y lo que ha salido mal. De esta manera el siguiente equipo que
realice un proyecto similar no cometerá, al menos, los mismos errores.
TÉCNICAS Y HERRAMIENTAS (TECHNIQUES AND TOOLS):
El equipo de dirección del proyecto debe utilizar el juicio experto para mediante
reuniones con las partes interesadas más relevantes elaborar este documento y tratar de
aprovechar técnicas de facilitación para hacer estas reuniones más efectivas.
Juicio de expertos (Expert judgement)

El juicio de los expertos es la única herramienta y técnica que se utiliza en este
proceso. Implica confiar en personas o grupos que tienen experiencia, formación,
conocimientos o habilidades en las áreas que estamos evaluando.
Estas personas pueden ser las partes interesadas, consultores, expertos de la organi-
zación, expertos en el tema concreto, la Oficina de Dirección de Proyectos (Project
Management Office, PMO), si la organización la tuviera, o expertos del sector.
Será muy útil al valorar los factores ambientales y los activos de la organización la
experiencia del comité ejecutivo o técnico para comprender mejor cómo el proyecto
se integra en la estrategia general de la empresa o la de anteriores project managers que

han gestionado proyectos similares.
Recopilación de datos (Data Gathering)

Las principales técnicas de recopilación de datos que se utilizan en este proceso son:
• Tormenta de ideas. Técnica utilizada para identificar un conjunto de ideas crea-
tivas en un corto período de tiempo. Se trata de una técnica de recopilación en
grupo que, mediante una reunión abierta y conducida por un facilitador, reco-
pila un conjunto de ideas lanzadas por los asistentes, que posteriormente serán
analizadas. Esta técnica puede ser utilizada para desarrollar el acta de constitución
mediante la recopilación de datos o ideas de los interesados, expertos en la
materia y miembros del equipo.
• Grupos de opinión. En este caso un grupo determinado de partes interesadas o
expertos en una materia comparten y discuten sobre sus ideas y puntos de vista
en relación al proyecto, siendo moderado por un agente externo que puede ser
el project manager.
• Entrevistas. El project manager entrevista a las partes interesadas en un diálogo
directo y preferentemente individualizado para así identificar sus requerimientos
para un determinado elemento del producto o del proyecto en general. Estos
encuentros pueden ser llevados a cabo vía videoconferencia, teléfono, presen-
cial…
Habilidades inter-personales y de equipo (Interpersonal and Team Skills)

Las principales habilidades interpersonales y de equipo que se utilizan en este proceso
son:
• Gestión de conflictos. Utilizada para tratar de acercar a los interesados hacia una
alineación con los objetivos, criterios de éxito, requisitos de alto nivel, hitos y
cualquier otro elemento marcado en el acta de constitución. Es ahora, cuando
comienza el proyecto, cuando más importante es asegurar que todos los intere-
sados clave están alineados.
• Facilitación. Como habilidad que permite guiar al grupo hacia decisiones satis-
factorias. El facilitador realiza una labor de liderazgo, asegurando la participación
y el correcto entendimiento por parte de los participantes en una reunión. Ade-
más, deberá asegurar el acuerdo de todas las partes en las conclusiones obtenidas.
• Gestión de reuniones. Implica gestionar adecuadamente las reuniones realizando
acciones como la preparación de la agenda, comunicación del lugar y hora de
reunión, conducción de la reunión tratando de cumplir la agenda y horario,
obtención de decisiones y accione acordadas, envío del acta correspondiente y
seguimiento.
Reuniones (Meetings)
Las reuniones serán realizadas principalmente con los interesados clave con el pro-
pósito de identificar los objetivos del proyecto, criterios de aceptación y el resto de
componentes del acta de constitución.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtendrá el Acta de Constitución que docu-

mentará la necesidad de negocio, el conocimiento actual de las necesidades del cliente
y el nuevo producto o servicio que se pretende satisfacer.
Puede incluir el propósito o justificación del proyecto, los objetivos medibles del
proyecto y los criterios de éxito, los requerimientos de alto nivel, la descripción de alto
nivel del proyecto, los riesgos de alto nivel, una síntesis de hitos del cronograma, un
presupuesto preliminar resumido, una lista de partes interesadas, los requerimientos de
aprobación del proyecto (qué implica el éxito del proyecto, quien va a decidir que el
proyecto ha sido un éxito…), el project manager y sponsor asignados y su responsabi-

lidad y nivel de autoridad.
Además se generará un registro de asunciones que contendrá información sobre las
asunciones tomadas al inicio del proyecto.
El Acta de Constitución (Project charter)

Como único resultado de este proceso está el Acta de Constitución (project charter),
escrito oficial de reconocimiento de que el proyecto está en marcha, que lo firma el
sponsor o el cliente (si coinciden), que le da al project manager la autoridad para asignar
recursos de la organización al proyecto.
Se utiliza para presentar el proyecto ante la organización y el consejo de dirección,
los directores funcionales y demás partes interesadas para que tengan una primera visión
de la relevancia y beneficios del proyecto para la organización.
Será entrada para los siguientes procesos:
• Elaborar el Plan de Dirección del Proyecto.
• Planificar la Gestión del Alcance.
• Recopilar requisitos.
• Definir el alcance.
• Planificar la gestión del cronograma.
• Planificar la gestión de costes.
• Planificar la gestión de riesgos.
• Identificar los interesados.
En este documento deben participar muy activamente al menos las partes interesadas
más relevantes (key stakeholders). Los pasos son:
1. Puesta a punto y preparación final del Acta de Constitución (project char-
ter):
Un Acta de Constitución bien documentada debe incluir al menos los siguientes
elementos:
• Descripción, objeto y justificación del proyecto.
• Los objetivos del proyecto, medibles.
• Una lista de los requerimientos de más alto nivel.
• Entregables clave del proyecto, basado en los requerimientos de negocio
para gestionar sus expectativas y enfocar el proyecto hacia el cumplimiento
de los objetivos.
• Supuestos y restricciones de alto nivel.
• Una descripción somera del proyecto.
• Una descripción somera de los riesgos más relevantes.
• Una síntesis del cronograma de hitos y entregables más relevantes.
• Un presupuesto general estimado.
• Lista de interesados más relevantes.
• Criterios de aprobación del proyecto: cómo se medirá el éxito del pro-
yecto.
• El nombre del project manager y su nivel de autoridad.

• El nombre de quien ha autorizado el proyecto-patrocinador (sponsor)
2. Firma del Acta de Constitución (sign off project charter)
El Acta no estará cerrada hasta que no sea firmada por la persona que la autoriza,
la alta dirección (dependiendo de la envergadura del proyecto) y las partes
interesadas clave que, de esa manera, muestran su apoyo, acuerdo y compro-
miso.
3. Publicación del Acta de Constitución (distribute project charter)
Es el último paso que consiste en, al menos, distribuir una copia a las partes
interesadas, el cliente, el equipo de dirección y otras personas que pueden o
deben estar al corriente. Esta comunicación del acta servirá además para asegurar
el correcto entendimiento por parte de los interesados de los entregables clave,
hitos, roles y responsabilidades. En la siguiente tabla se presenta un ejemplo de
Acta de Constitución:
ACTA DE CONSTITUCIÓN
1. Título del Proyecto
2. Origen de la solicitud de la oferta (cliente, comercial, agente..).
3. Destino geográfico del proyecto
Objetivos del Proyecto para la empresa (Estratégicos, Comerciales, Económicos, Téc-

4.
nicos…)
4.1 Estratégico
4.2 Comercial
4.3 Económico
4.4 Técnico
4.5 Otros
5. Descripción general del Proyecto y del Producto
6. Requerimientos de Alto nivel del Proyecto y Producto y Criterios de Aceptación
7. Hipótesis y Restricciones de Proyecto más Relevantes
8. Entregables del Proyecto necesarios para que el cliente lo dé por completo
9. Plazo total e Hitos más Relevantes
10. Elementos Críticos y Características Clave
Necesidades de Recursos Críticos (Humanos, Equipamiento y/o Instalaciones) Espe-

11.
ciales
ACTA DE CONSTITUCIÓN
12. Riesgos y Oportunidades más Importantes
Conclusiones respecto a la factibilidad del proyecto y directrices para gestionar pro-

13.
yecto
APROBACIÓN
Evaluado por: Revisado por: Aprobado por:
Registro de asunciones (Asumption Log)

Almacena las asunciones y restricciones que se toman en el proyecto.
Las asunciones y restricciones principales suelen venir reflejadas en el caso de nego-
cio, antes de comenzar el proyecto.
En ocasiones el log de asunciones se incluye como un apartado más del Acta de
Constitución, pero será sin duda más manejable si se genera en un entregable indepen-
diente.
2.2. GESTIÓN DE LOS INTERESADOS DEL PROYECTO
La gestión de las partes interesadas incluye los procesos destinados a:

• Identificar todas las personas, grupos y organizaciones que estén afectadas –o se
puedan sentir afectadas– por el proyecto.
• Identificar sus necesidades y expectativas.
• Evaluar su relevancia –analizando su interés e impacto en el proyecto–.
• Y definir la mejor estrategia para lograr su participación positiva y minimizar su
participación negativa en el proyecto.
Una de las claves del éxito del proyecto será el que el project manager mantenga
una comunicación fluida con las partes interesadas más relevantes y se asegure su parti-
cipación en el proyecto identificando problemas con suficiente antelación para tomar
las medidas oportunas.
La gestión de las partes interesadas, como se observa en el esquema siguiente, incluye
cuatro procesos que se reparten en diferentes grupos de procesos del proyecto:
Gestión de los interesados del proyecto 115
Como vimos en el capítulo anterior existen algunas diferencias entre los procesos de la Guía
del PMBOK y la ISO21500 en lo que a gestión de las partes interesadas se refiere. En el
siguiente cuadro se reflejan los procesos de PMBOK y los de ISO21500 (estos últimos en
cursiva).

Identificar los Planificar la ges- Gestionar la impli- Monitorizar la
interesadas tión de interesados cación de los involucración de
(Identificar a las interesados los interesados
partes (Gestionar a las par-
interesadas) tes
interesadas)
Este proceso, aunque se realiza en el Inicio, debe mantenerse abierto

durante todo el proyecto. Trata de identificar con mayor detalle aque-
llas personas u organizaciones que puedan verse afectadas positiva o
negativamente por el proyecto, que vayan a recibir información o
deban aportarla.
Asimismo, se determinarán todos sus requerimientos, expectativas
Identificar los intere- (menos claras y más complejas de traducir en requerimientos) y sus
sados intereses en el proyecto. Todo ello antes de que empiece el proyecto
(Identify stakehol- ya que, cuanto más tarde se identifiquen, mayores serán los retrasos,
ders) costes y conflictos.
Para poder clasificarlos y abordar los requerimientos de todas las partes
interesadas de forma priorizada, se evaluará su nivel de influencia, su
capacidad para influir positiva o negativamente en el éxito del proyecto.
No existen diferencias sustanciales entre PMBOK 6.ª Edición e ISO21500

manteniendo también la denominación del proceso.
Teniendo en cuenta sus necesidades y expectativas, los requerimientos

que solicitan para el proyecto y su resultado, y su interés e impacto en
Planificar la involu- el proyecto, el project manager elabora la estrategia para garantizar el
cración de los intere- máximo apoyo de aquellas partes interesadas con interés positivo en el
sados proyecto y minimizar el impacto negativo de aquellas partes interesadas
(Plan stakeholder con intereses y percepciones negativas del proyecto.
engagement) No existe este proceso en ISO21500 ya que se supone que al realizar la iden-
tificación de partes interesadas se definen ya las estrategias y el plan para su
implicación.
Durante la fase de proyecto se producen cambios, conflictos, inciden-
cias… que el project manager deberá gestionar informando a las partes
interesadas, valorando cómo afecta a sus expectativas y permitiéndoles
que tomen las decisiones más adecuadas con la mejor información
posible.
Gestionar la involu- Para ello, en todo momento, el project manager debe mantener una
cración de los intere- comunicación fluida con los interesados clave, invitarles a las presen-
sados taciones y que reciban los informes de estado y estén al tanto de los
(Manage stakeholder cambios más relevantes y las decisiones tomadas que afecten a su par-
engagement) ticipación o expectativas en el proyecto.
No existen diferencias sustanciales entre PMBOK 6.ª Edición e ISO21500

salvo la diferencia en la denominación del proceso que en ISO21500 es Ges-
tionar los interesadas (Manage Stakeholders).
Este proceso tiene por objeto controlar que las estrategias planificadas
Monitorizar la parti- y ejecutadas cumplen su objetivo, detectar si se están produciendo
cipación de los problemas que requieran un ajuste de dichas estrategias y, en caso afir-
mativo, proceder a su modificación.
interesados (Control
stakeholders engage- No existe este proceso en ISO21500 ya que las actividades que implica se
ment) suponen incluidas en el proceso Gestionar los interesadas (Manage Stakehol-
ders).
2.2.1. Identificar a los interesados

Los interesados son individuos, grupos u organizaciones que puedan ser afectados
(o percibir que están afectados) por una decisión, actividad o resultado del proyecto.
Pueden verse afectados positiva o negativamente (y tendrán, por lo tanto, intereses
positivos o negativos en relación al proyecto).
Es crítico para el éxito del proyecto que se identifiquen todos los interesados rele-
vantes en las primeras etapas del proyecto para recoger sus necesidades, expectativas y
requisitos respecto al producto o proyecto. En cualquier caso, el project manager debe
estar atento a la aparición de nuevos interesados durante la vida del proyecto.
En este proceso se identifican todas las personas, grupos y organizaciones afectados
por el proyecto, analizando y documentando sus intereses, participación, interdepen-
dencias e impacto potencial sobre el proyecto. Este ejercicio permitirá al project mana-
ger centrar sus esfuerzos en gestionar aquellas partes interesadas con mayor relevancia e
impacto en el proyecto.
Las partes interesadas (Stakeholders)

Identificar, apoyarse en y gestionar las expectativas de las partes interesadas de un
proyecto, es probablemente el mayor reto del project manager tanto por su complejidad
como por el impacto que una mala gestión de esta área puede tener en el proyecto –no
en vano es uno de los cambios más significativos en la nueva versión del PMBOK®: la
creación de una nueva área de conocimiento sobre gestión de las partes interesadas–.
Las partes interesadas pueden verse afectadas –o sentirse afectadas– positiva y nega-
tivamente por el proyecto por lo que, dependiendo de cuál sea su posición respecto al
proyecto y su capacidad de afectar al desarrollo y cumplimiento de los objetivos del
proyecto, el project manager deberá definir la estrategia más adecuada para lograr su
participación o minimizar su rechazo.
Lo primero que debe hacer el project manager, una vez que dispone del Acta de
Constitución y el Enunciado del Trabajo del Proyecto (Project Statement of Work,
SOW), es identificar a todas las partes interesadas, determinar todas sus necesidades,
expectativas, requerimientos, su actitud ante el proyecto y su capacidad de influir en él,
tanto positiva como negativamente. Y toda esta información, revisarla y tratar de incor-
porarla al Alcance del Proyecto y del producto.
Como resultado formal de todas estas actividades el director del proyecto generará
un registro de interesados (stakeholders register).
Las partes interesadas más habituales

Entre las partes interesadas que irán presentándose durante el proceso hay algunas
que serán comunes a prácticamente todos los proyectos, que son:
a) El cliente (Customer)
Es el verdadero «jefe», el único que puede despedir a toda la compañía, desde
el director general hacia abajo, decidiendo simplemente invertir su dinero en
otra parte.
Es muy importante recordar siempre que, en caso de conflicto, debe prevalecer

la opinión del cliente –lo que no quita para que se le trate de informar justifi-
cadamente de otras alternativas y puntos de vista que el patrocinador (sponsor)
o el project manager consideren oportuno–.
b) El patrocinador (Sponsor)
Suele ser la persona que financia e impulsa el proyecto, quien lo defiende ante
otros proyectos. En ocasiones coincide con el cliente. En estos casos, se nombra
un patrocinador interno que haga de enlace con el cliente. Busca apoyo de las
partes interesadas y de la alta dirección para el proyecto. Normalmente es un
alto ejecutivo de la organización que tiene el poder y la autoridad para tomar
decisiones y cerrar conflictos que de otra manera no se cerrarían, afectando al
avance del proyecto.
Su nombre debe aparecer en el Acta de Constitución del Proyecto y ser iden-
tificado como la máxima autoridad y la persona con mayor capacidad de decisión
en lo que respecta al proyecto.
Suele tener una mayor participación en las fases de inicio y planificación y menos
en las siguientes, aunque será responsabilidad del project manager el mantenerlo
informado.
Es la persona de enlace entre el project manager y la compañía y el cliente. Las
comunicaciones hacia el cliente son su responsabilidad.
c) Gestores de carteras y programas (Portfolio y program managers)
Los program managers gestionan grupos de proyectos relacionados entre sí que
se gestionan utilizando las mismas técnicas y de una manera coordinada para
lograr beneficios que, de realizarse cada proyecto por separado, no se lograrían.
Si el proyecto forma parte de un programa más amplio se deberá tener en cuenta
al program manager.
De igual manera el gestor de la cartera de programas y proyectos, como res-
ponsable de gestionar y lograr que los programas y proyectos estén alineados
con un objetivo de negocio específico, deberá ser consultado sobre los cambios
que en el proyecto de produzcan por si no fueran compatibles con el origen del
proyecto y los objetivos estratégicos a los que se dirigía.
d) La Oficina de Gestión de Proyectos (Project management office)
En cualquiera de sus formas –desde el centro de excelencia hasta la oficina res-
ponsable de proyectos– es un elemento clave de apoyo y consejo. Puede sumi-
nistrar apoyo en los costes y plazos, formación al project manager y su equipo
dotándoles de las habilidades necesarias para ser eficientes gestores.
e) El project manager
Asume la responsabilidad del éxito del proyecto, debe ser nombrado lo antes
posible para que pueda participar en la redacción del Acta de Constitución
(project charter). Entre sus funciones están las de:
• Planificar y dirigir la ejecución del proyecto.
• Asegurarse de que cada uno conoce sus funciones y responsabilidades y
sabe lo que significa que el proyecto sea un éxito porque tiene claros los
objetivos.
• Asegurarse de que cada uno tiene la información que necesita en el
momento adecuado para tomar las decisiones que le correspondan.
• Establecer los estándares y políticas para los proyectos que dirija.
• Establecer y comunicar al equipo de trabajo y las partes interesadas los
procedimientos a utilizar en el proyecto (cuáles y con qué grado de deta-
lle).
• Identificar las actividades y tareas, necesidades de recursos, costes de pro-
yectos, requisitos del proyecto, medidas de desempeño u otras más.
Pero, sobre todo, mantener alineados y trabajando en equipo a partes interesa-
das, quien autorizó el proyecto y al equipo de trabajo del proyecto.
f) Directores funcionales (Functional managers)
Son los responsables de las diferentes áreas técnicas implicadas en el proyecto,
los directores de departamentos técnicos, los jefes funcionales. Ellos se encargan
de las tareas administrativas de la organización de su departamento, facilitan
personal de su equipo al proyecto y llevan a cabo evaluaciones de desempeño

de su personal en el proyecto. En estructuras matriciales su personal reporta tanto
al project manager como al director de su departamento.
g) El equipo de trabajo (Project team)
Será el responsable de ejecutar las actividades definidas en el proyecto y colaborar
con el project manager en todos aquellos aspectos que aquel considere necesa-
rios.
h) Los proveedores o vendedores (Sellers)
Si el proyecto requiere adquirir productos y servicios que no pueden realizar
con el equipo y personal de la compañía se contratarán a proveedores externos.
En estos casos, los proveedores serán también partes interesadas y con un
impacto tanto mayor cuanto más relevante sea el paquete de trabajo o producto
o servicio contratado.
i) El departamento de operaciones (Operations department)
En muchos casos, la empresa tiene una producción en marcha con un departa-
mento de operaciones gestionándola. Si la empresa lanza proyectos para desa-
rrollar nuevos productos tendrá que tener en cuenta al personal de operaciones,
quienes podrán dar su opinión especializada de las implicaciones del diseño y
los requerimientos del producto sobre la producción posterior del mismo y
viceversa.
j. Administraciones y organizaciones (Authorities and social represen-
tatives)
La empresa realiza sus actividades y ubica el resultado de sus proyectos en un
entorno social que debe tener en cuenta: administraciones, comunidades de
vecinos, grupos ambientalistas… que, si no se tienen en cuenta, pueden retrasar
el proyecto o llegar incluso a hacerlo inviable.
El proceso de identificar a los interesados (Identify stalkeholders)

Este proceso busca identificar y documentar todas las partes interesadas que en
un proyecto tienen algo que ganar o que perder –incluyendo sus intereses,
expectativas, temores e impactos positivos o negativos en ellos y su actividad–
y su capacidad de influir de forma más o menos importante en él, identificando
quién se verá afectado por el proyecto y cómo vas a ser la comunicación con
cada uno:
En el siguiente esquema se presenta el proceso:
Para ISO21500 el proceso tiene también como objetivo identificar individuos, grupos y
organizaciones afectadas o que puedan afectar al proyecto y documentar información relevante
sobre sus intereses e implicación.
Entradas Salidas
Acta de Constitución Registro de partes interesadas
Organigrama de la organización del
proyecto
IDENTIFICAR A LAS PARTES INTERESADAS (IDENTIFY STA-

KEHOLDERS):
Este proceso busca identificar y documentar todas las partes interesadas que en
un proyecto tienen algo que ganar o que perder –incluyendo sus intereses, expec-
tativas, temores e impactos positivos o negativos en ellos y su actividad– y su
capacidad de influir de forma más o menos importante en él, identificando quién

se verá afectado por el proyecto y cómo vas a ser la comunicación con cada uno.
ENTRADAS (INPUTS):
Serán de gran utilidad el Acta de Constitución –que corresponde al área de cono-

cimiento de «gestión de la integración»– donde aparecerá un primer listado de partes
interesadas más relevantes, los documentos del contrato (si procede) que han dado lugar
al proyecto, los documentos de negocio –donde hay identificados interesados el pro-
yecto-, los factores ambientales de la organización (la cultura y la estructura organizativa
de la empresa…) y los procesos de la organización (plantillas para registro de partes
interesadas, lecciones aprendidas y registros de partes interesadas de otros proyectos…).
Una vez ya comenzado el proyecto, y en el proceso iterativo de identificar intere-
sados que se llevará a cabo a lo largo de todo el proyecto, también se usarán como entrada
el plan de dirección del proyecto con sus planes subsidiarios, y la documentación de
proyecto disponible.

Es un escrito oficial de reconocimiento de que el proyecto está en marcha, que da
al project manager la autoridad para asignar recursos de la organización al proyecto y
que da una primera pero centrada visión del alcance, entregables, hitos, riesgos de alto
nivel, principales interesados y la relevancia y beneficios del proyecto para la organiza-
ción. Será de utilidad para este proceso ya que puede dar información sobre partes
interesadas internas y externas a la organización que hay que tener en cuenta.
Los documentos de adquisiciones (Procurement documents)

En caso en que la compañía sea proveedora de servicios y no cliente, las diferentes

partes del contrato serán partes interesadas en el proyecto. Los proveedores, por ejemplo,
deberán ser considerados como una parte interesada más.
Documentos de negocio (Business documents)

El business case y el plan de gestión de los beneficios son una fuente valiosa de
información para detectar interesados del proyecto.
Plan de gestión del proyecto (Project management plan)

No está disponible durante la primera identificación de interesados. Una vez desa-
rrollado, hay componentes que pueden ayudar a identificar interesados a lo largo del
proyecto: plan de gestión de interesados y plan de gestión de comunicaciones.
Documentos de proyecto (Project documents)

No disponibles durante la primera identificación de interesados. A medida que
avanza el proyecto, estos documentos se convierten en una fuente de información para
identificar a nuevos interesados.
Los factores ambientales de la empresa (Enterprise environmental factors)

Hay que prestar especial atención a la cultura de empresa, la estructura organizativa
y los estándares establecidos por la industria, sector en el que desarrolla su actividad la
organización y las administraciones públicas y, por último, las prácticas habituales en el
lugar en el que se desarrolla la actividad.
Los activos de los procesos de la organización (Organizational process assets)

Algunos serán útiles ya que permitirán utilizar experiencias pasadas: plantillas de
registro de interesados (stakeholders register templates), lecciones aprendidas (lessons
learned) en su identificación, procedimientos establecidos y listas de interesados en pro-
yectos similares que faciliten el trabajo en el nuevo proyecto.
Se deberá recoger y analizar de forma sistemática información cuantitativa y cuali-

tativa para determinar qué intereses deben tenerse en cuenta a lo largo de la vida del
proyecto. Se deben identificar los intereses, expectativas y capacidad de influencia de
las diferentes partes interesadas y se debe relacionar con los objetivos del proyecto.
Conviene identificar las interrelaciones entre diferentes stakeholders que permitan crear
alianzas para garantizar el éxito del proyecto.
Para lograr obtener un registro completo y útil el project manager deberá contar
con la opinión y experiencia de la dirección, departamentos funcionales, partes intere-
sadas clave ya identificadas, compañeros que gestionaron proyectos similares…

Es importante contar con el apoyo de personal interno (dirección general, otras
unidades de la empresa, directores de proyectos similares,) y externo (expertos en el
negocio, asociaciones profesionales, asesores…).
El formato puede ser diverso desde entrevistas, método delphi… o el que se con-
sidere más oportuno para las características del proyecto (tiempo, complejidad…).
Permitirán un mayor conocimiento de los interesados del proyecto y analizar la
información relativa a ellos.
Recopilación de información (Data gathering)

Cuestionarios, encuestas, sesiones de lluvia de ideas (brainstorming) o de escritura
de ideas (brainwriting) serán herramientas adecuadas para recoger información acerca
de interesados potenciales del proyecto.
Análisis de datos (Data analysis)

Principalmente centrado en el análisis de la documentación disponible del proyecto
y el análisis de las partes interesadas.
Análisis de las partes interesadas (Stakeholders analysis)

Para cada parte interesada se trata de conocer y comprender sus expectativas, sus
necesidades… para de ahí poder ir buscando otras más relacionadas con los objetivos
del proyecto y los entregables.
Es importante no olvidar que a las partes interesadas les preocupa lo que ellos, o sus
organizaciones, van a ganar o perder o tener que cambiar. Van a mirar por sus intereses
y conviene que el project manager se ponga en su lugar sin perder la perspectiva global
del proyecto y sus objetivos.
Asimismo es importante ser capaces de aprovechar la posibilidad de crear alianzas y
acuerdos potenciales para lograr los objetivos del proyecto.
Siguiendo la metodología PMBOK® son tres los pasos que hay que dar para realizar
este análisis: Identificar a los interesados, identificar el potencial impacto que su apoyo
o rechazo puede generar en el proyecto y valorar cómo van a reaccionar ante diferentes
situaciones que pueden darse durante el proyecto:
1. Identificar todas las potenciales partes interesadas y recoger información
general sobre ellos –trabajo, funciones, conocimientos, nivel de influencia.
Como ya se ha comentado, las partes interesadas pueden ser tanto internas a la
organización como externas. Descubrir todas las partes relevantes nos obliga a
llevar un proceso de búsqueda iterativo e ir preguntando a los ya identificados

por otros que pueden estar interesados o afectados.
2. El segundo paso es el de evaluar el potencial impacto que su apoyo o rechazo
puede tener en el desarrollo exitoso del proyecto. Para ello se clasifican de
acuerdo a su impacto potencial para tratar de tener una estrategia individualizada
para los considerados más relevantes. Para ello, conviene conocerles, identificar
sus intereses y determinar las posibles relaciones con otros interesados.
Algunos interesados pueden tener una influencia significativa sobre el proyecto
y sus resultados. Si comprendemos la estructura organizativa y dónde se ubican
los interesados, habremos dado un primer e importante paso para acotar su
influencia. Sería grave para un project manager atender las solicitudes de un
interesado con poca influencia y autoridad y que cuando aparezca el realmente
importante se deba rehacer trabajos ya avanzados con el siguiente coste, retraso
y conflictos.
3. El tercer y último paso es valorar la influencia y los potenciales impactos

negativos que pueden tener en el proyecto.
Representación de datos (data representation)

Para facilitar la clasificación de las partes interesadas, PMBOK® sugiere la utilización
de los siguientes métodos:
• La matriz poder-interés que agrupa a los interesados basándose en el nivel de
autoridad (poder) y su nivel de preocupación (interés).
• La matriz poder-influencia: los agrupa basándose en su nivel de autoridad

(poder) y su participación activa (influencia).
• La matriz influencia-impacto: los agrupa basándose en su participación activa

(influencia) en el proyecto y su capacidad de efectuar cambios a la planificación
o ejecución del proyecto (impacto).
• El modelo de prominencia (salience model) que representa tres factores: el poder
del interesado, la urgencia con la que debe recibir una respuesta satisfactoria y
su legitimidad –necesidad y oportunidad de que un interesado participe con su
opinión en determinados temas en diferentes fases del proceso–.
• Cubo de interesados (stakeholder cube): es la versión tridimensional de las
matrices anteriores.
• Direcciones de influencia (directions of influence): clasifica a los interesados de
acuerdo a su influencia en el trabajo del proyecto o en el equipo de proyecto.
SALIDAS (OUTPUTS):
Como resultado del proceso de identificar las partes interesadas, se obtendrá un

registro de partes interesadas que, al menos, incluirá información básica, una valoración
de su relevancia y una clasificación de cada parte interesada.
El registro de interesados (Stakeholders register)

Contiene la información que se ha indicado anteriormente y que se recomienda
elaborar utilizando una sencilla plantilla que, además de la información ya indicada,
deberá tener al menos:
• Información identificativa –información de contacto, departamento, fun-
ción…–.
• Información de valoración –influencia, expectativas, requerimientos más
importantes, momento en que su participación puede ser más relevante sino
crítica–.
• Y su clasificación –internos o externos, a favor o en contra del proyecto o indi-
ferentes–.
Un ejemplo de plantilla en la que se recomienda plasmar toda la información relativa
a las partes interesadas es la siguiente:
Registro de interesados (Stakeholders register)
Nombre Sr. Rodríguez Blanco

Asistir a las reuniones mensuales
Responsabilidades Identificar riesgos de mercado del producto
Departamento Ingeniería
Lanzar el nuevo producto al mercado para las fiestas de

Objetivos
Navidad
Poder disponer de información actualizada mensualmente

Expectativas del desempeño y del Plan de Gestión de los Riesgos del
Proyecto (project risk management)
Poder disponer de información actualizada mensualmente

Requerimientos del desempeño y del Plan de Gestión de los Riesgos del
Proyecto (Project Risk Management)
Impacto/Influencia (de 1 a 5) Impacto 2 / Influencia 4
Positiva pero con preocupación ante la posibilidad de que

Actitud hacia el proyecto
afecte a sus sistemas de seguridad de la información
Grupo Cliente
Solicitud de cambios (change request)

Esta salida no se dará en la identificación inicial de interesados. Sí en las identifica-
ciones periódicas durante el proyecto. Solicitudes de cambio en el producto, planes y
documentación del proyecto. Siempre a través del control integrado de cambios.
Actualizaciones en el plan de dirección del proyecto (project management

plan updates)
ciones periódicas durante el proyecto.
Actualizaciones en documentos de proyecto (project documents updates)

ciones periódicas durante el proyecto.
2.3. ESTABLECER EL EQUIPO DE PROYECTO (ISO21500)

En la Guía de PMBOK, aunque se supone que existe una primera asignación de
personas al proyecto para ayudar al project manager a elaborar el Plan de Dirección de
Proyecto empezando por la definición del alcance, no aparece ningún proceso en el
grupo de procesos de inicio relacionado con los recursos humanos.
En cualquier caso, es lógico pensar y es como, en definitiva, se gestiona un proyecto,
que el project manager debe presentar el proyecto a los diferentes departamentos fun-
cionales de la organización y solicitarles recursos para, junto con él, proceder a la pla-
nificación del proyecto.
Si el equipo asignado es el que finalmente participará en el proyecto tendrá una
doble ventaja: que conocerán el proyecto y que habrán hecho suyo el Plan de Dirección.
En ISO21500 se propone un tercer proceso en el grupo de procesos de inicio denominado

Establecer el Equipo de Proyecto (Establish Project Team) que tiene por objetivo adquirir las
personas necesarias para ejecutar el proyecto.
De acuerdo a este proceso, el project manager debe definir cómo y cuándo se deben incorporar
los diferentes perfiles profesionales al proyecto y cuando deben liberarse y, si es necesario, qué
perfiles y cómo se van a subcontratar o adquirir externamente. También debe definir los roles y
responsabilidades.
Entradas Salidas
Requerimientos de recursos
Organigrama del proyecto Asignaciones de personal
Disponibilidad de recursos Contratos de personal
Planes de proyecto
Descripciones de roles
Establecer el equipo de proyecto (ISO21500) 127
En PMBOK 6.ª Edición, este proceso aparece en el grupo de procesos de planificación

(Planificar la Gestión de Recursos Humanos) y ejecución (Adquirir el equipo de proyecto)
mientras que en ISO21500 se recoge en el grupo de procesos de inicio.
En este proceso de ISO21500 el project manager debe determinar qué recursos, cuándo y
cómo va a ser necesario adquirir mientras que en el proceso Adquirir el Equipo de PMBOK
6.ª Edición, se refiere a adquirir el equipo definitivo.
En cualquier caso, este proceso no se cierra hasta que en la fase de planificación se estiman
los recursos (tanto en el caso de PMBOK como ISO21500) –de hecho se puede observar que
entre sus entradas están los recursos requeridos que, como veremos más adelante, son una salida
del proceso de planificar los recursos humanos.
3.
Planificación del proyecto
Esquema general de la fase de planificación del proyecto

En esta fase, una vez definida la existencia de un proyecto y sus objetivos, necesi-
dades y requerimientos de alto nivel del cliente, sabemos QUÉ quiere el cliente –refle-
jado en el Acta de Constitución (project charter)– así como A QUIÉN debemos tener
en cuenta –las partes interesadas (stakeholders)– durante toda la vida del proyecto.
Comienza la fase de planificación en la que definiremos QUIÉN hace QUÉ y para
CUÁNDO, todo ello manteniendo unos procesos y procedimientos básicos de gestión.
El esquema a seguir en el grupo de procesos de planificación es difícil representarlo
mediante un esquema lineal ya que existen muchas interrelaciones entre los diferentes
procesos –las salidas de unos son entradas para otros pero, una vez acabados estos últimos,
el resultado de estos modifica los primeros–. Por ejemplo:
• La Definición del Alcance y la creación de la EDT informan al Plan de Gestión
de la Calidad pero a su vez las actividades de calidad habrá que incorporarlas al
alcance.
• La Identificación de Riesgos tiene como entradas el Alcance, el cronograma o
el Presupuesto, pero una vez definidas las medidas de mitigación éstas afectarán
al Alcance, al cronograma y al Presupuesto.
El siguiente esquema pretende representar una propuesta de orden cronológico en
el que los procesos se van abordando de izquierda a derecha y de arriba abajo, no olvi-
dando el carácter iterativo de buena parte de ellos.
Este orden será el que se utilice en la presentación del grupo de procesos de plani-
ficación.
130 Planificación del proyecto
Este orden pretende ser coherente con las principales relaciones de entradas y salidas
establecidas por PMBOK. De acuerdo a lo indicado en este esquema, la planificación
de un proyecto y la presentación de los procesos de planificación en este manual seguirán
el siguiente orden:
Con los resultados de los Procesos de Inicio –el Acta de Constitución y el registro
de partes interesadas– se puede proceder a:
• Abrir el Plan de Dirección del Proyecto.
• Y elaborar el Plan de Gestión de interesados.
Utilizando el Acta de Constitución y el Plan para la Dirección del Proyecto se
procede a elaborar:
• Plan de Gestión del Alcance.
Con el Acta de Constitución, el Registro de interesados, el Plan de Gestión del
Alcance y el Plan de Gestión de interesados, se puede proceder a:
• Recopilar los requisitos.
• Definir el alcance.
• Y crear la EDT.
Planificación del proyecto 131
Una vez obtenida la línea de base de alcance, habiendo recogido los requisitos,
definido el alcance y desglosado el trabajo del proyecto en la EDT, se puede hacer:
• Un Plan de Recursos preliminar (con un calendario de recursos preliminar).
• Por otra, un Plan de Adquisiciones preliminar.
Una vez obtenida la línea de base, habiendo recogido los requisitos y definido el
alcance, se puede también:
• Planificar la Gestión de la Calidad (que se cerrará al concluir el registro de ries-
gos) y actualizar la EDT con las actividades de calidad.
• Y, si se ha realizado después que el cronograma y presupuesto, actualizar el
cronograma y el presupuesto con las actividades de calidad.
Con el Acta de Constitución y el Plan de Dirección del Proyecto se puede proceder
a planificar la gestión del cronograma (para cerrarla se necesitará el calendario de recursos
definitivo y el registro de riesgos para ajustar el resultado) abordando los procesos de:
• Planificar la gestión del cronograma.
• Y, con la línea de base del alcance, definir las actividades.
• Y, con el Enunciado del Alcance, secuenciar las actividades.
• Estimar los recursos necesarios para cada actividad.
• Estimar la duración de cada una de las actividades.
• Elaborar el cronograma.
Como ocurría con el cronograma, con el Acta de Constitución y el Plan de Direc-
ción de Proyecto, se puede iniciar los procesos (para cerrarlos se necesitará el calendario
de recursos definitivos, los contratos de adquisiciones y el registro de riesgos) de:
• Planificar la gestión de costes.
• Estimar los costes (con el Plan de Recursos Humanos preliminar).
• Elaborar el presupuesto (con calendario de recursos y contratos de compra pre-
liminares).
Definido el alcance del trabajo y haber obtenido los requerimientos de recursos para
cada actividad (obtenidos al planificar el cronograma y los costes), se puede:
• Planificar (definitivamente) la gestión de recursos humanos.
• Y, aunque forme parte de los procesos de ejecución, adquirir el equipo.
Una vez conocidos los interesados –y elaborado su Plan de Gestión– y redactado el
Plan de Recursos Humanos –y asignando roles y responsabilidades– se puede proceder
a:
• Planificar la gestión de la comunicación.
Con el Plan de Dirección del Proyecto y teniendo en cuenta los resultados de pla-
nificar la gestión de partes interesadas, alcance, tiempo, coste, calidad, recursos humanos
y comunicaciones, se puede:
• Planificar la gestión de riesgos.
• Identificar los riesgos.
• Realizar el análisis cualitativo de riesgos.

• Realizar el análisis cuantitativo de riesgos.
• Planificar la respuesta a los riesgos.
Una vez elaborado el Plan de Respuesta a los Riesgos, con sus planes de mitigación,
sus planes de contingencia y sus reservas de contingencia, se puede proceder a:
• Cerrar la EDT.
• Cerrar el cronograma.
• Cerrar el Presupuesto.
• Cerrar el Plan de Gestión de partes interesadas.
• Cerrar el Plan de Calidad.
• Cerrar el Plan de Recursos Humanos.
• Cerrar el Plan de Comunicaciones.
• Cerrar el Plan de Adquisiciones.
• Cerrar el Plan de Dirección del Proyecto.
Cerrado el Plan de Dirección de Proyecto se puede realizar la reunión de inicio en
la que presentar y aprobar el Plan de Dirección y dar comienzo a la fase de ejecución
del proyecto.
Todas estas actividades se irán desarrollando en los siguientes capítulos. En ellos
veremos cómo se organiza y coordina el proyecto, cómo se planifica el alcance, el plazo,
los costes, los recursos humanos y materiales, la calidad, las comunicaciones entre todas
las partes interesadas y, por último, pero por ello no menos importante, los riesgos.
3.1. ELABORAR EL PLAN DE DIRECCIÓN DEL PROYECTO
Una vez firmada el Acta de Constitución y elaborado el registro de partes interesadas

el project manager procede elaborar el Plan de Dirección del Proyecto. En este proceso,
de acuerdo a Project Management Institute, A Guide to the Project Management Body of
Knowledge (PMBOK® Guide) – Sixth Edition, Project Management Institute, Inc., 2017, se:
• Documentarán las acciones necesarias para definir, preparar e integrar y coor-

dinar todos los Planes Subsidiarios.
• Definirá la manera en que se va a ejecutar, supervisar, controlar y cerrar el pro-
yecto.
Su alcance variará en función de la complejidad del proyecto y el área de apli-
cación. Al crear el Plan de Dirección del Proyecto (Project Management Plan)
el project manager
• Debe preguntarse cómo va a definir, planificar, gestionar y controlar el coste,
alcance, plazo… del proyecto.
• Debe tratar de visualizar cómo tiene que desarrollarse el proyecto para, de esta
manera, planificarlo y definir cómo lo va a gestionar, monitorizar y controlar.
Será un plan único para cada proyecto porque abordará las necesidades particulares
del mismo.
Elaborar el plan de dirección del proyecto 133
Lógicamente, el formato y nivel de detalle dependerá de la complejidad, necesida-

des, forma de trabajar de la empresa y perfil del project manager. Probablemente haya
proyectos en los que no se apliquen los 49 procesos descritos en PMBOK® Guide. Sin
embargo sí que deben considerar, y si no se aplican, documentar por qué y cuál va a ser
la alternativa para garantizar que se cumplan los objetivos de este proceso.
Al iniciar la planificación es cuando el project manager toma realmente el control
del proyecto y redacta este plan que dice exactamente cómo va a manejar todos los
aspectos y áreas de conocimiento del proyecto. El Plan de Dirección del Proyecto
organiza toda la información sobre el proyecto en un único documento para que todas
las partes interesadas sepan exactamente qué tiene que ocurrir cuando ellos hagan el
trabajo que tienen asignado.
Siempre que haya algún problema en el proyecto, el project manager debe consultar
en el Plan para la Dirección del Proyecto cómo actuar. No deberá pensarlo ni impro-
visar. Debe consultar el Plan de Dirección donde estará definido cómo proceder.
3.1.1. Desarrollar el plan de dirección del proyecto

Lo primero que debe hacer el project manager es crear un borrador del Plan de
Dirección del Proyecto (Project Management Plan) que se irá completando durante
todo el proceso de planificación y al final del mismo se cerrará y pasará al patrocinador
y partes interesadas relevantes para su aprobación. El esquema general de ubicación de
este proceso, dentro del área de conocimiento y grupos de procesos, es el siguiente:
Puesto que es un aspecto relevante y que conviene tener claro, en el siguiente

esquema se indica la relación entre el Acta de Constitución (project charter) y este Plan
de Dirección del Proyecto (Project Management Plan):
• el cliente o patrocinador crean y aprueban el Acta de Constitución,
• que permite al project manager elaborar el Plan de Dirección del Proyecto,
• que deberá ser finalmente aprobado por el patrocinador (sponsor).
El grupo de procesos de planificación (planning processes) es donde se plasma cómo

se va a llevar a cabo el proyecto, ya que se necesita un plan antes de poner a trabajar a
todo el equipo. En esta fase es en la que se reflexiona sobre todo lo que puede pasar en
el proyecto y tratar de preparar estrategias que permitan completarlo con el menor
número de errores posibles.
También es donde se plantea cómo se gestionarán los cambios que ocurran durante
la fase de ejecución, porque todos los proyectos tienen problemas y contratiempos que
requieren cambios en el plan inicial sin que necesariamente implique que se tenga que
cambiar el rumbo del proyecto o abandonarlo. Si la gestión es la adecuada, se estudiarán
los cambios, se aprobarán y se reconducirá el proyecto.
Este Plan deberá ser:

• Acordado por todas las partes.
• Aprobado formalmente.
• Realista.
• Darle la forma de documento formal que se usa y controla durante toda la vida
del proyecto.
Este Plan deberá ser revisado y aprobado en última instancia por el patrocinador.
Entre las acciones más importantes que deben llevarse a cabo para elaborar el Plan
de Dirección del Proyecto están:
• Determinar la propia metodología para elaborarlo.
• Establecer el sistema de comunicación para su elaboración y cambios.
• Reunirse con las partes interesadas identificadas para definir su papel en el pro-
yecto.
• Reunirse con los directores funcionales con los que se deberá acordar la dedi-
cación de parte de su equipo al proyecto de manera total o parcial.
• Evaluar el impacto de éste en otros proyectos y viceversa.
• Crear los documentos que conforman este plan.
Para desarrollar el Plan para la Dirección del Proyecto (develop project management
plan) se necesitarán los siguientes datos de entrada (inputs), se utilizarán las siguientes
técnicas y herramientas (techniques and tools) y se obtendrán los siguientes resultados
o salidas (outputs):
ISO21500 propone un proceso similar denominado «Elaborar los planes de proyecto

(Deevelop Project plans)» cuyo objetivo es documentar por qué se aborda el proyecto, qué debe
realizarse y quién debe hacerlo, cómo debe hacerse, cuánto costará y cómo se ejecutará, controlará
y cerrará el proyecto.
Los planes de proyecto constan del Plan de Proyecto y el Plan de Gestión del Proyecto.
Pueden ser documentos separados o integrarse en un único documento.
El Plan de Gestión de Proyecto recoge cómo se va a ejecutar, controlar y cerrar el proyecto
y suele definir los roles, responsabilidades, organización y procedimientos para la gestión del
alcance, cronograma, costes, riesgos, calidad...
Por su parte, el Plan de Proyecto contiene las líneas de base para ejecutar el proyecto y
todas las salidas relevantes de los procesos del grupo de procesos de planificación.
Entradas Salidas
Acta de Constitución
Planes Subsidiarios
Lecciones aprendidas de proyectos Plan de Proyecto
anteriores Plan de Gestión del Proyecto
Caso de negocio
Cambios aprobados
Cabe destacar que estos planes deben mantenerse actualizados y comunicar los cambios a
las partes interesadas. De igual manera, dependiendo de la naturaleza del proyecto, puede
comenzarse con una definición de alto nivel del proyecto e ir detallándolo conforme se avance y
se tenga más información.
DESARROLLAR EL PLAN DE DIRECCIÓN DEL PROYECTO (DEVE-

LOP PROJECT MANAGEMENT PLAN):
En este documento se reflejarán las acciones necesarias para definir, preparar,
integrar y coordinar todos los Planes Subsidiarios asociados con cada una de las res-
tantes áreas de conocimiento. Define cómo se ejecutará, monitorizará y controlará y
cerrará el proyecto.
ENTRADAS (INPUTS):
Entre la información necesaria para elaborarlo están el Acta de Constitución –que

define los límites del proyecto y su aprobación da paso a la fase de planificación– y las
salidas de otros procesos (todos los Planes Subsidiarios y las líneas de base de alcance,
coste, plazo y calidad), así como factores ambientales de la empresa (como su organi-
zación y cultura) y los activos de los procesos de la organización (guías estandarizadas,
instrucciones de trabajo, procesos y plantillas de planes de dirección de proyectos, pro-
cedimientos de control de cambios, archivos de proyectos anteriores, información his-
tórica y lecciones aprendidas).
Acta de Constitución del Proyecto (Project charter)

Es un escrito oficial que reconoce que el proyecto existe, que se pone en marcha,
que define y da al project manager la autoridad para asignar recursos de la organización
al proyecto, que da una primera, pero centrada, visión de la relevancia y beneficios del
proyecto para la organización, que define los riesgos de alto nivel e incluye estimaciones
previas de presupuesto, plazo, hitos y entregables.
A la hora de elaborar el Plan de Dirección del Proyecto tiene especial relevancia la

información relativa a los límites del proyecto recogidos en el acta. No se puede iniciar
el Plan para la Dirección sin haberse formado y, por tanto, aprobado formalmente su
Acta de Constitución.
Salidas de los procesos de planificación (Planning processes outputs)

El Plan de Dirección del Proyecto es un único documento pero se compone de
varios Planes Subsidiarios que se presentan en el siguiente esquema del que el Plan de
Dirección hace de documento integrador:

En este conjunto de datos de partida y condicionantes, que se repetirá a lo largo de
todo el libro, se consultará la forma en que la compañía trabaja. La compañía puede (y
debería) tener información corporativa realmente interesante a utilizar en la fase de
proyecto que ayude al project manager a enfocar su gestión.
El project manager deberá saber cómo funciona cada departamento técnico, las
condiciones del mercado en que se mueve la empresa, la estrategia global de la empresa,

las políticas, la cultura de la empresa («cómo se hacen los cosas aquí»), los sistemas de
información para la Dirección de Proyectos implantados, la infraestructura e instalacio-
nes y otros aspectos sobre el personal que compone la compañía.
Un elemento clave será el sistema de autorización de trabajos (work authorization
system) que determina cómo asigna la compañía los trabajos a su personal y asegura que
se realizan las tareas de forma adecuada y en el orden establecido.
Activos de los procesos de organización (Organizacional process assets)

Son otros datos de entrada que aparecerá frecuentemente como entradas de proce-
sos. Darán información de cómo se suelen gestionar los proyectos en la empresa. Cada
compañía tiene sus maneras, protocolos, procedimientos establecidos para llevar a cabo
un proyecto, plantillas para las solicitudes, para los documentos… que el project manager
deberá crear durante el proyecto.
En el desarrollo del Plan Para la Dirección del Proyecto habrá que tener en cuenta
muy especialmente las instrucciones, directrices, procedimientos de evaluación de pro-
puestas y evaluación del desempeño, los procedimientos de control de cambios (change
control procedures) así como el conocimiento corporativo (archivo de proyectos ante-
riores, información histórica, lecciones aprendidas, sistemas de gestión de las versiones
de documentos, planos…).
Uno de los activos más importantes son las lecciones aprendidas (lessons learned)
durante proyectos anteriores. Permitirán aprovechar información muy útil sobre pro-
yectos similares.
Por ello, en cada proyecto, es responsabilidad del project manager reunirse con su
equipo y partes interesadas y documentar todo lo que se ha aprendido durante el pro-
yecto, lo que ha salido bien y lo que ha salido mal. De esta manera el siguiente project
manager que gestione un proyecto similar podrá aplicar lo aprendido y tendrá más pro-
babilidades de no cometer los mismos errores y de aplicar técnicas que han resultado
exitosas en proyectos anteriores.
Para elaborar este importante documento el project manager debe utilizar el juicio
experto propio de las partes interesadas más relevantes y miembros del equipo de direc-
ción para adaptar los procesos a las necesidades del proyecto, desarrollar detalles técnicos
y de gestión a incorporar en el plan, determinar recursos y niveles de habilidades para
ejecutar el proyecto, definir el nivel de control de la configuración a aplicar en el pro-
yecto y definir qué documentos van a someterse al control integrado de cambios.

Será una herramienta que el project manager utilizará muy habitualmente ya que,
desde su labor de coordinación general, ni puede ser ni debe actuar como un especialista
en cada uno de los aspectos que implica un proyecto.

Por ello puede necesitar recopilar experiencias e información sobre cada problema
o aspecto del proyecto de los diferentes departamentos o confiar en consultores externos
o grupos industriales, proveedores..., que pueden informar de cómo se han abordado
determinados proyectos y cómo se han resuelto los problemas que han ido surgiendo.
En el caso de la elaboración del Plan de Dirección del Proyecto los expertos ayu-
darán a adaptar los procesos a las necesidades del proyecto, desarrollar detalles técnicos
y de gestión, priorizar proyectos y, de acuerdo a ello, asignar recursos y capacidades y,
muy importante, qué documentos estarán sujetos al proceso normal de control de cam-
bios.

• Tormenta de ideas. Utilizada en este proceso para recopilar ideas y soluciones

al respecto del enfoque del proyecto. A estas reuniones generalmente asisten
miembros del equipo así como otros expertos en la materia o incluso otros
interesados.
• Listas de verificación. Son listas estandarizadas que guían al Project manager para
desarrollar el plan verificando que todos los puntos del proceso han sido cubier-
tos. Suelen estar basadas en la experiencia de la organización o aportadas de la
comunidad (industria).
• Grupos de opinión. Utilizados en este caso para integrar los diferentes compo-
nentes del plan de dirección del proyecto.
• Entrevistas. Utilizadas para obtener información específica sobre cualquier ele-
mento que compone el plan de dirección del proyecto.
Habilidades inter personales y de equipo (Interprersonal anda Team Skills)

Las principales habilidades interpersonales y de equipo que se utilizan en este proceso
son:
• Gestión de conflictos. Utilizada para asegurar que los interesados están alineados
con todos los aspectos descritos en el plan de dirección del proyecto.
• Facilitación. Como habilidad que permite guiar al grupo hacia decisiones satis-
factorias. El facilitador realiza una labor de liderazgo, asegurando la participación
y el correcto entendimiento por parte de los participantes en una reunión. Ade-
más, deberá asegurar el acuerdo de todas las partes en las conclusiones obtenidas.
• Gestión de reuniones. Implica gestionar adecuadamente las reuniones, hacién-
dolas eficientes, teniendo en cuenta que la elaboración del plan de dirección del
proyecto implicará seguramente la realización de numerosas reuniones.
Las reuniones serán realizadas principalmente con los interesados clave con el pro-
pósito trabajar y elaborar el plan de dirección del proyecto.
Una reunión particular a realizar en este proceso será la reunión de inicio del pro-
yecto o kick-off meeting. El objetivo principal de esta reunión es comunicar los objetivos
del proyecto así como el plan completo a ejecutar. Esta reunión se realiza una vez
completado el plan de dirección del proyecto y marcará el punto de inicio de la ejecu-
ción del proyecto.
SALIDAS (OUTPUTS):
Como salidas de este proceso se obtendrá el Plan de Dirección del Proyecto que
integrará y consolidará todos los Planes Subsidiarios y líneas de base y abordará aspectos
como: el ciclo de vida seleccionado y sus puntos de control, los procesos de gestión de
proyectos seleccionados, el nivel de implementación de estos procesos, la descripción
de las técnicas y herramientas a utilizar, la descripción de cómo se van a utilizar para

gestionar el proyecto concreto, el Plan de Control de Cambios y de Control de la
Configuración, la descripción de cómo se va a mantener la línea de base de desempeño
(alcance, tiempo, coste) actualizada...
Plan para la Dirección del Proyecto (Project management plan)
El Plan para la Dirección del Proyecto será un único documento que deberá ser
consensuado con las personas implicadas en el proyecto, que necesita ser formalmente
aprobado, distribuido y explicado, para que todos los participantes lo conozcan y lo
hagan suyo.
Debe, por tanto, ser aprobado formalmente –esto es, firmado– por la dirección, el
patrocinador, el equipo de proyecto y el resto de las partes interesadas. Un proyecto no
puede iniciarse sin una aprobación formal del Plan para la Dirección del Proyecto.
Este Plan es muy importante ya que será entrada para todos los procesos del grupo
de planificación, control y cierre.
En el Plan de Dirección se reflejarán decisiones sobre la forma de gestionar el pro-
yecto, como los procesos de gestión de proyectos seleccionados, el nivel de detalle, rigor
e implementación de cada uno, la descripción de las técnicas y herramientas que se
utilizarán.
Además de definir aspectos generales de la dirección del proyecto –cómo se va
abordar la realización del proyecto (ciclo de vida seleccionado para el proyecto, procesos
y grado de detalle a aplicar en cada fase, técnicas y herramientas seleccionadas, etc.).,
reflexiones sobre las situaciones que se pueden dar y cómo resolverlas y tratar de esta-
blecer una forma de actuar que lleve el proyecto al éxito– incluirá un esquema similar
al siguiente:
• Las líneas de base (baselines) de:
– Costes: presupuesto acumulado a lo largo de la vida del proyecto.
– Plazo: el cronograma con fechas de inicio, hitos y fecha de finalización.
– Alcance: con el Enunciado del Trabajo, la Estructura de Desglose de
Tareas y el diccionario de la EDT.

Respecto a las que se comparará el avance y el desempeño real en la fase de
ejecución del proyecto y permitirá detectar y evaluar las desviaciones que se
produzcan y proponer, si procede, cambios –siempre siguiendo el proceso de
gestión integrada de cambios–.
• Los Planes Subsidiarios comentados anteriormente:
– Plan de Gestión del Alcance.
– Plan de Gestión de Requisitos.
– Plan de Gestión del Cronograma.
– Plan de Gestión de Costes.
– Plan de Gestión de la Calidad.
– Plan de Mejora de Procesos.
– Plan de Gestión de Recursos Humanos.
– Plan de Gestión del Personal.
– Plan de Gestión de la Comunicación.
– Plan de Gestión de los Riesgos del Proyecto.

– Plan de Gestión de Adquisiciones de Proyecto.
– Plan de Gestión de los interesados.
Y, por último, dos planes importantes:
– Plan de Gestión de Cambios y
– Plan de Gestión de la Configuración
El Plan de Gestión de Cambios (Change Management Plan)

El responsable de proyecto velará desde el inicio porque los cambios se gestionen
de tal manera que se asegure que se encuentran dentro del alcance del proyecto y que,
si se aprueban, se comunican a todas las partes interesadas. Es su responsabilidad, por
tanto, asegurar que los cambios están dentro del alcance y son beneficiosos para el pro-
yecto, que se define cómo se van a implementar y gestionar los cambios durante su
implantación.
Se puede, y se debe en proyectos importantes, definir un Comité de Control de
Cambios como autoridad para la aprobación de todos los cambios de proyecto pro-
puestos. La composición dependerá de la complejidad y características del proyecto.
El responsable de proyecto y, si existe, el comité de control de cambios aprobarán
todos los cambios en coste y el cronograma que no superen el límite máximo fijado para
el responsable de proyecto.
El Sponsor o quien se haya definido en el proceso deberá aprobar todos los cambios
que superen la capacidad de decisión del responsable de proyecto o equipo de dirección
y, sobre todo, los que afecten a los objetivos del proyecto y al Acta de Constitución.
El Responsable de Proyecto debe centralizar todas las solicitudes de cambios, realizar
un análisis preliminar del impacto del cambio en riesgos, costes, plazos y alcance antes
de someterlos al Comité. El Equipo de Dirección de Proyecto y los miembros del
equipo de proyecto enviarán las solicitudes de cambio según el formato establecido y

con la información complementaria necesaria para valorar el cambio.
El Proceso de control de cambios debe permitir que el responsable de proyecto y
el equipo de dirección del proyecto incorporen los cambios aprobados, comuniquen
los cambios y actualicen la documentación de proyecto. El proceso que se presenta
como ejemplo consta de los siguientes pasos:
1. Cualquiera de las partes interesadas identifica la necesidad de un cambio y remite
una solicitud de cambio –con la información definida en la plantilla correspon-
diente (ver ejemplo en tabla siguiente)– al responsable de proyecto.
Proyecto
Responsable del Proyecto
Solicitado por Fecha
Evaluado por Fecha
Aprobado/Denegado por Fecha
Identificación de Solicitud de Cambio
Código Solicitud de Cambio
Denominación del Cambio
Detalles de la solicitud de Cambio
Descripción
Justificación
Causa
Prioridad
Evaluación
Impacto sobre alcance (PT-EDT)
Impacto sobre el cronograma
Impacto en los costes /presupuesto
Impacto en la calidad (Requisitos)
Impacto en los riesgos
Alternativas y recomendación
Decisión:
✓ Aprobada
▪ Denegada
▪ Retenida
Cómo ejecutar el cambio
2. El responsable de proyecto recoge la solicitud de cambio en «Registro de Cam-

bios».
Registro de Control de Cambios
Proyecto: Responsable de Proyecto:

Resolu-
Título Priori- Solici- Fecha
Código: (aLink ción /
de Estado resolu-
ficha) dad tante Comenta-
Cambio ción rios
3. El responsable de proyecto hace una evaluación preliminar del impacto del

cambio en el alcance (EDT), el presupuesto, el cronograma, la calidad y los
riesgos del proyecto.
4. El responsable de proyecto envía la solicitud de cambio y su análisis preliminar
al Comité de Control de Cambios para su revisión.
5. El Comité de Control de Cambios discute el cambio propuesto y decide si se
aprueba y en qué condiciones o se rechaza.
6. El responsable de proyecto define la implementación del cambio con la persona
responsable de ejecutar el cambio y asegura que se realiza el cambio adecuada-
mente y se informa a las partes interesadas y se actualizan los documentos de
proyecto necesarios de acuerdo al Plan de Gestión de la Configuración.
Plan de Gestión de la Configuración (Configuration Management Plan)

Forma parte del Sistema de Información para la Gestión del Proyecto (Project
management information system). Contiene los procedimientos, procesos y herramien-
tas de gestión corporativas para gestionar los cambios que se produzcan en los entregables
(deliverables) del proyecto para asegurar que todas las partes interesadas tienen la última
versión y ésta está actualizada.
Como se ha indicado anteriormente, este Plan de Dirección del Proyecto se definirá
a modo de borrador en el inicio del proceso de planificación y se irá completando con
los resultados de los planes de gestión subsidiarios del alcance, el plazo, el coste..., para,
una vez cerrados los Planes Subsidiarios, incorporarlos a este Plan de Dirección de Pro-
yecto, realizar los ajustes necesarios en el mismo y presentarlo al cliente, patrocinadores
y demás partes interesadas en la reunión de inicio de la ejecución (Kick-off meeting)
para su aprobación formal.
El plan de dirección del proyecto es el principal documento a utilizar para gestionar
el proyecto. Sin embargo hay otros documentos útiles para la gestión del proyecto que
no están incluidos en el plan.

La siguiente figura refleja los componentes del Plan de Dirección del Proyecto así
como el resto de documentos del proyecto:
3.2. PLANIFICAR LA GESTIÓN DE LOS INTERESADOS EN EL PROYECTO
Una vez que se tiene el Acta de Constitución y el registro de partes interesadas y se

ha decidido qué ciclo de vida, qué procesos y con qué grado de detalle se van a aplicar
al proyecto concreto, es el momento de planificar cómo se van a gestionar todas las
partes interesadas.
Si bien el Plan de Gestión de Partes Interesadas es un documento vivo que, como
todos, se irá actualizando y completando durante todo el proceso de planificación (y
durante la ejecución del proyecto), es éste el momento de iniciarlo porque es en éste
plan en el que definiremos cómo vamos a implicar a las diferentes partes interesadas en
la definición del alcance, entre otros.
Es el proceso mediante el cual se desarrollan las estrategias de gestión más adecuadas

para lograr la participación efectiva de las partes interesadas en las decisiones y ejecución
del proyecto, todo ello teniendo en cuenta sus necesidades, expectativas, intereses e
impacto potencial.
Este plan identifica cómo afectará el proyecto a las diferentes partes interesadas lo
que permitirá al equipo de proyecto definir diferentes formas de implicarlas en el pro-
yecto, gestionar sus expectativas y, en definitiva, lograr la aceptación y compromiso con
En el siguiente esquema vemos su ubicación dentro del área de conocimiento de
gestión de partes interesadas y el grupo de procesos de planificación:
Planificar la gestión de los interesados en el proyecto 145
En el siguiente esquema se presentan las entradas, técnicas y herramientas y salidas

que se detallarán a continuación:
ISO21500 no tiene este proceso aunque sus actividades se encuentran repartidas en otros
procesos como «Identificar Partes Interesadas», «Planificar las Comunicaciones» o «Gestionar
las partes interesadas».
PLANIFICAR LA GESTIÓN DE LOS INTERESADOS (PLAN STA-

KEHOLDERS MANAGEMENT):
Es el proceso mediante el cual se desarrollan las estrategias de gestión más ade-
cuadas para lograr satisfacer las necesidades y lograr la participación efectiva de las
partes interesadas en las decisiones y ejecución del proyecto, todo ello teniendo en
cuenta sus necesidades, expectativas, intereses e impacto potencial.
ENTRADAS (INPUTS):

El acta de constitución del proyecto contiene información acerca del propósito del
proyecto, objetivos y criterios de éxito a tener en cuenta a la hora de planificar la par-
ticipación de los interesados.
Plan de Dirección del Proyecto (Project Management Plan)

El Plan de Dirección del Proyecto es el plan que recoge e integra el resto de planes.
Entre la información de este plan, que será de ayuda para elaborar el Plan de Gestión
de los Interesados, está el ciclo de vida seleccionado y los procesos a aplicar en cada fase,
cómo se van a ejecutar los trabajos de proyecto, cómo se van a adquirir los recursos
humanos para el proyecto, cómo se van a gestionar los riesgos y las comunicaciones.
Documentos de proyecto (project documents)

Importantes tras la primera planificación (en las revisiones periódicas del plan) serán:
registro de asunciones, registro de cambios, registro de incidentes, cronograma del pro-
yecto, registro de riesgos, registro de interesados.
En concreto, el registro de interesados (Stakeholders Register) es la principal entrada
ya que dará información sobre todas las partes interesadas, sus necesidades y expectativas,
su interés y su impacto, en definitiva su relevancia para el proyecto. Esta información
ayudará a seleccionar las mejores estrategias para maximizar su apoyo y minimizar su
oposición al proyecto.
Acuerdos (agreements):
La participación de proveedores debe ser planificada junto con el equipo de compras
para asegurar que la relación se gestiona de forma efectiva.
Factores ambientales de la empresa (Entreprise environmental factors)

Los factores ambientales de la empresa son entradas para todos los procesos de pla-
nificación ya que dan el marco y los condicionantes para la organización del proyecto.
Dependiendo de cuál sea la cultura, la estructura, los procesos y el clima de la organi-
zación, las estrategias para gestionar las partes interesadas serán unas u otras y el project
manager deberá tenerlas en consideración para elegir la estrategia de gestión de las partes
interesadas más adecuada.
Activos de los procesos de la organización (Organizational process assets)

Las lecciones aprendidas y documentación histórica sobre proyectos similares será
de gran ayuda para que el project manager pueda definir la mejor estrategia de gestión
de cada parte interesada.
TOOLS AND TECHNIQUES (TÉCNICAS Y HERRAMIENTAS):
Se deberá aprovechar la experiencia de la dirección, departamentos funcionales,

partes interesadas más relevantes, otros project managers, expertos..., para decidir el nivel
de participación de cada parte interesada requerido en cada fase del proyecto. La estra-
tegia será diferente en función de si la parte interesada desconoce el proyecto, se resiste
al proyecto, es neutral al proyecto, apoya el proyecto o, más aún, lidera e impulsa el
proyecto. Además, su posición puede evolucionar durante la vida del proyecto.
Planificar la gestión de los interesados en el proyecto 147
Juicio de expertos (Experts Judgment)

Se deberá aprovechar la experiencia de la dirección, departamentos funcionales,
partes interesadas más relevantes, otros project managers, expertos, miembros de equipo
de proyecto, consultores, asociaciones técnicas…, para decidir el nivel de participación
de cada parte interesada requerido en cada fase del proyecto.
Se deben mantener reuniones con expertos y miembros del equipo para evaluar y
discutir las mejores estrategias para gestionar las partes interesadas.
Recopilación de datos (data gathering)

Por ejemplo, las evaluaciones comparativas o benchmarking del resultado del análisis
de interesados con otras organizaciones o proyectos de referencia.
Análisis de datos (data analysis)

Al análisis de asunciones y restricciones, análisis de causa raíz y análisis DAFO
(Debilidades, Amenazas, Fortalezas y Oportunidades) serán las principales herramientas
de análisis de datos a utilizar en este proceso.
Toma de decisiones (decision making)

Por ejemplo, la priorización (prioritization) y la clasificación (ranking) de los requi-
sitos de los interesados y de los propios interesados.
Representación de datos (data representation)

La estrategia será diferente en función de si la parte interesada desconoce el proyecto,
se resiste al proyecto, es neutral al proyecto, apoya el proyecto o, más aún, lidera e
impulsa el proyecto. La participación actual se puede recoger en una matriz de eva-

luación de la participación de los interesados (stakeholders engagement assessment
matrix). Es por ello que el project manager debe clasificar a las partes interesadas en
función de su posición respecto al proyecto, comparar la participación actual frente a la
deseada y establecer la estrategia más adecuada.
Los mapas mentales también son herramientas utilizadas en este proceso para orga-
nizar visualmente la información acerca de los interesados y sus relaciones.
SALIDAS (OUTPUTS):
Plan de Gestión de la participación de los interesados (Stakeholder Engage-

ment Plan)
Como resultado del proceso se obtendrá un Plan de Gestión de los Interesados –
más o menos formal, más o menos extenso, dependiendo de las características del pro-
yecto– que, además de la información del registro de partes interesadas, incluirá al

menos, la siguiente información:
• El nivel de participación actual y deseado de cada parte interesada.
• Alcance e impacto de los cambios en los interesados.
• Los requisitos de comunicación de cada parte interesada.
• La información a enviar a cada parte interesada (contenido, formato, frecuencia,
nivel de detalle…).
• La razón para distribuir esta información a cada parte interesada y el impacto
previsto (por y para qué se le envía).
• Cuándo y cada cuánto tiempo se les debe informar y contactar.
3.3. PLANIFICAR EL ALCANCE DEL PROYECTO
En el grupo de procesos de esta área de conocimiento se definen todos los trabajos

y actividades a realizar y sólo los trabajos a realizar. Lo que aparece en la Estructura de
Desglose del Trabajo (EDT) está en el alcance y hay que realizarlo. Lo que no está, no
está en el alcance, el cliente no lo va a pagar y no se hace. Estos procesos se repiten
varias veces a lo largo de la vida del proyecto si se produce, por ejemplo, un cambio en
el alcance (scope change) inicial.
Una vez definidas las líneas maestras del Plan de Dirección –ciclo de vida del pro-
yecto y procesos que se van a aplicar y el grado de detalle que se hará– y el Plan de
Gestión de Interesados –a qué personas u organizaciones vamos a tener en cuenta a la
hora de definir los requerimientos del producto, servicio o resultado y del proyecto–,
podemos proceder a planificar el Alcance del proyecto.
En la fase de planificación se definen y detallan los entregables y los requerimientos
del producto o servicio, se crea el Plan de Gestión del Alcance (Scope Management
Plan) y se crea la Estructura de Desglose de Trabajo (EDT).
En la fase de seguimiento y control se comprueba que los entregables cumplen las
condiciones establecidas, se controlan los cambios en estos procesos y se solicita la apro-

bación parcial de documentos por parte del cliente –validar el alcance (validate scope)–.
Esta área engloba tanto el alcance del producto (product scope) como el del proyecto
(project scope):
• El alcance del producto se refiere a las características del servicio, producto o
resultado del proyecto. Su éxito se mide en función del grado de cumplimiento
de los requerimientos del producto establecidos por el cliente.
• El alcance del proyecto se refiere a la gestión de las tareas a realizar durante el
proceso. En este caso, el control se hace con el Plan de Dirección del Proyecto,
el documento de requisitos del proyecto, la EDT y el Diccionario de la EDT
que se verán posteriormente.
Planificar el alcance del proyecto 149
3.3.1. La gestión del alcance del proyecto

Antes de centrarnos en la planificación del alcance, hacemos una breve introducción
a la gestión del alcance del proyecto y los procesos que se ejecutan a lo largo de su vida.
La gestión del alcance del proyecto (project scope management) es un área de
conocimiento que incluye los siguientes seis procesos:
• Planificar la gestión del alcance (plan scope management).
• Recopilar requisitos (collect requirements).
• Definir el alcance (define scope).
• Crear la Estructura de Desglose de Tareas, EDT (create Work Breakdown
Structure).
• Validar el alcance (validate scope).
• Controlar el alcance (control scope).
Mediante los cuales:
• Por una parte se define cómo se va planificar y gestionar el alcance y se definen
qué trabajos están incluidos en el proyecto y cuáles no.
• Y, por otra, se establece los mecanismos para asegurar que todo el trabajo que
hay que hacer, y sólo el que hay que hacer, se haga.
Se definirán los requerimientos que debe cumplir el proyecto y, para eso, se tendrá
en cuenta a todas las partes interesadas, actividad que llevará su tiempo, pero que garan-
tizará que lo que incluye el proyecto recoge sus necesidades y expectativas.
Se incluirán las actividades encaminadas a planificar con antelación cómo se va a
definir el alcance del proyecto, cómo se va a controlar su cumplimiento, cómo se va a
verificar su alcance y aprobar formalmente antes de iniciar los trabajos.
Si estas fases previas han sido realizadas de forma detallada y organizada, durante la
fase de proyecto se podrá controlar las actividades que ya se han completado, las que
están en curso, y comprobar que, estas últimas, realmente están incluidas en la EDT.
Si hay nuevas actividades por solicitudes de cambios que afecten al alcance, éstas
deberán ser evaluadas conforme a un proceso establecido que valore su impacto en el
coste, el plazo, la calidad, los riesgos, los recursos…, como condición previa a su apro-
bación o rechazo.
En definitiva, el Plan de Gestión del alcance del proyecto (Scope Management Plan)
tratará de responder a las siguientes preguntas:
• Cómo va a ser planificado el alcance.
• Cómo se va a crear la EDT y su Diccionario.
• Cómo va a ser ejecutado el alcance y cómo va a ser controlado y validado.
Un error habitual es comenzar a trabajar en un proyecto antes de finalizar el alcance
del producto y del proyecto y, sin tener claro qué es lo que hay que hacer, definir,
entonces, sobre la marcha cómo hacerlo. Esto lleva a que en la fase de ejecución del
proyecto aparezcan cambios en el alcance incontrolados, que nadie se había preguntado
qué efecto podrían tener sobre el plazo, coste, calidad o necesidad de recursos del pro-
yecto.
Los seis procesos incluidos en el área de conocimiento de gestión del alcance del
proyecto (Project scope management) tienen por objetivos:
• Definir cómo se va a identificar todo el trabajo que el equipo tendrá que realizar
durante el proyecto,
• Asegurarse de que se va a realizar todo el trabajo escrito y documentado y nada
más que ese.
• Asegurarse de que, cuando cambien las cosas en el proyecto, se mantenga el
alcance actualizado para que el equipo de proyecto esté realizando el trabajo
correcto.
Todo ello se deberá recoger en el Plan de Gestión del Alcance (Scope Management
Plan) que evitará que el equipo no sepa por dónde empezar, que haya varios amagos de
comienzo, que las partes interesadas sean impredecibles y vayan apareciendo y dando
sus aportaciones sobre la marcha, que haya cambios sin aviso en los trabajos a realizar,
en su alcance, en sus prioridades...
En el esquema siguiente se observa el grupo de procesos relacionados con la plani-
ficación y gestión del alcance del proyecto (project scope management) que se verán de
forma individualizada a continuación. Como se puede observar los procesos se centran
en los grupos de planificación y supervisión y Control.
Como vimos en el primer capítulo existen algunas diferencias entre los procesos de la Guía
del PMBOK y la ISO21500 en lo que a gestión del alcance se refiere. En el siguiente cuadro
se reflejan los procesos de PMBOK y los de ISO21500 (estos últimos en cursiva).

Planificar la gestión del Controlar el alcance
alcance Validar el alcance
Recoger requisitos (Controlar el alcance)
Definir el alcance
Crear la EDT
(Definir el alcance)
(Crear la EDT)
(Definir actividades)
Estos seis procesos, que se presentan con más detalle en los próximos puntos, se
introducen brevemente en la siguiente tabla:
Se crea el Plan para la Gestión del Alcance que documenta cómo se va

Planificar la Gestión a definir, validar y controlar el alcance.
del Alcance (Plan
scope management) No existe este proceso en ISO21500 (se considera que se elabora al preparar
el Plan de Dirección del Proyecto y sus Planes Subsidiarios).
Se recogen los requisitos de producto y de proyecto de los interesados
y se documentan para que el equipo sepa qué tiene que construir o
Recopilar requisitos proyectar y que los requisitos puedan medirse y controlarse.
(Collect require-
ments) No existe este proceso en ISO21500 ya que las actividades asociadas al proceso
de Recopilar Requisitos de PMBOK se incluyen en el proceso de Definir el
Alcance.
Se escribe una descripción detallada del trabajo que va a hacer el equipo
y lo que va a producir como resultado.
Definir el alcance
(Define scope) En ISO21500 este proceso incorpora las actividades del proceso anterior de
«Recoger Requisitos» de PMBOK.
La estructura de desglose de trabajos EDT (work breakdown structure,
WBS) organiza el trabajo del equipo en paquetes de trabajo –unidades

de trabajo que los miembros del equipo ejecutan– para que ayude en
Crear la EDT la comunicación con interesados, la estimación de costes y plazos, la
(Create the WBS) evaluación y gestión de riesgos.
No existen diferencias en este proceso entre PMBOK e ISO21500.

Una vez terminado un entregable y habiéndolo revisado –proceso de
«Controlar la calidad» del proyecto– se entrega al cliente para que veri-
fique si está de acuerdo a lo establecido (validate scope) y lograr su
aprobación formal o la solicitud de cambios (changes request) que
Validar el alcance indique.
(Validate scope)
No existe este proceso en ISO21500 ya que sus actividades se incluyen dentro
del proceso de Cerrar el Proyecto o Fase en el que se logra la aceptación final
del cliente.
En este proceso se revisa que cada entregable cumpla con lo planificado
Control del alcance y que solamente se implementen los cambios aprobados. Si no se con-
(Control scope) trolan los cambios en el alcance del producto (product scope) se puede
llegar a situaciones frustrantes y que puedan dar al traste con el pro-
yecto, realizando tareas que ya no son necesarias y dejando de hacer

tareas que sí hay que hacer.
No existen diferencias en este proceso entre PMBOK e ISO21500.
La gestión del alcance del proyecto (project scope management) garantiza que el
proyecto incluya todo –y únicamente– el trabajo necesario para completarlo con éxito:
define qué está incluido y qué no está incluido en el proyecto.
Como se indicaba en la lista de actividades de Mulcahy (2011), la planificación del
alcance comienza con:
• La recogida de requerimientos del producto y del proyecto, completando y
concretando los requerimientos de alto nivel recogidos al elaborar el Acta de
Constitución (project charter).
• Y la elaboración del Enunciado del alcance del proyecto (project scope state-
ment).
Completadas estas tareas, el project manager debe hacer una valoración preliminar
de:
• Los paquetes de trabajo (work packages) que conviene subcontratar que se
completará y ajustará antes de cerrar el proceso de planificar las adquisiciones
(plan procurements).
• El equipo de proyecto necesario para abordar aquellas tareas que se van a realizar
con equipos propios y que se completará y ajustará antes de cerrar el proceso de
planificar los recursos humanos (plan human resources).
Predefinidos los recursos necesarios y las actividades a subcontratar, se elabora la
Estructura de Desglose del Trabajo EDT (work breakdown structure) que cierra, pro-
visionalmente, la planificación del alcance del proyecto. Su cierre definitivo será cuando
se incorporen las tareas procedentes del Plan de Calidad y el Plan de Respuesta a los
Riesgos, reflejo una vez más de que la planificación no es un proceso lineal sino iterativo.
Antes de proceder a describir en detalle los tres procesos de planificación del alcance
–recoger requerimientos, definir el alcance y elaborar la estructura desglosada de tareas–
trataremos de aclarar algunos conceptos:
Alcance del producto (Product scope) y alcance del proyecto (Project scope)
Son dos conceptos que conviene no confundir. El alcance del producto (product
scope) es el conjunto de características y funciones que definen un producto mientras
que el alcance del proyecto (project scope) es el trabajo que hay que realizar para entregar
el producto que lleve incorporadas dichas características y funciones.
El alcance del producto (product scope) se refiere, por tanto, a las características,
componentes, requerimientos, funcionalidades que debe tener el producto o servicio
final que entreguemos al cliente o patrocinador. Por ejemplo, si estamos diseñando un
programa informático serán alcances del producto: la necesidad de que tenga gráficos
en tres dimensiones, que sean compatible con diferentes sistemas operativos, que haya
cuatro niveles de dificultad o que puedan jugar 2 jugadores a la vez.
Por su parte, el alcance del proyecto recoge todas las actividades de definición,
planificación, ejecución, seguimiento y control necesarias para que ese producto, con
ese alcance, sea entregado al cliente cumpliendo además con los requisitos contractuales
de plazo, coste y calidad. En el caso del programa informático serían alcance del pro-
yecto: la programación, el diseño gráfico, las pruebas de ensayo, la elaboración del cro-
nograma, el documento de requisitos, el seguimiento y control de los riesgos...
En el caso de que el resultado final sea un producto (móvil, planta de fabricación,
modelo de coche…) el project/product manager debe:
• Empezar con el análisis de los requisitos y alcance del producto.
• Teniendo claro este alcance:
– Definir el trabajo que tienen que hacer el project manager y su equipo
para desarrollarlo y llevarlo a buen puerto –alcance del proyecto con todas
sus fases de planificación, ejecución, seguimiento…– (project scope mana-
gement).
– Pensar cómo lograrlo (project management plan).
Un producto, o un servicio, o un nuevo proceso organizativo, son el resultado de
un proyecto, y si el resultado es un producto (no un servicio) podríamos asimilar al
responsable del producto (product manager) como un director del proyecto (project
manager) cuyo objetivo es crear o lanzar ese producto asignado.
La finalización del proyecto se mide contra el Plan de Dirección de Proyecto,
mientras que la finalización del alcance del producto se mide contra la lista de requisitos
del producto.
Enunciado del Trabajo de Proyecto, Enunciado del Alcance del Proyecto y

Documentación de Requisitos
En ocasiones también se confunden estos dos conceptos:

• El Enunciado del Trabajo de Proyecto es la documentación que entrega el
cliente y que describe el alcance de los trabajos a realizar. En una entrada para
elaborar el Acta de Constitución.
• La Documentación de Requisitos que es el resultado del proceso de Recopilar
requisitos, que tiene por objeto identificar y documentar todos los requisitos de
producto y proyecto de todos los interesados del proyecto.
• El Enunciado del Alcance del Proyecto es el resultado del proceso de Definir el
Alcance y refleja el alcance del producto y del proyecto, es decir, lo que está
incluido en el proyecto.
La línea base del alcance del proyecto (Project scope baseline)

Este concepto es muy importante ya que permitirá supervisar, controlar y verificar,
durante la vida del proyecto, las variaciones del alcance del proyecto. Está compuesta por:
• Enunciado del alcance del proyecto (Project Scope Statement).

• Estructura de Desglose de Trabajo (Work breakdown structure).
• Diccionario de la EDT (WBS Dictionary).
El avance real del proyecto se comparará con esta línea de base y de esta comparación
se identificarán los adelantos y retrasos y se tomarán las medidas pertinentes para recon-
ducirlo.
Tendencias y Prácticas emergentes en Gestión de alcance (Trends and emer-

ging practices in Project Scope Management)
Los temas relacionados con la gestión de los requerimientos del proyecto siempre
han sido un asunto de vital importancia y siguen siéndolo en la gestión de proyectos.
Con la complejidad global del entorno, algunas organizaciones han empezado a
utilizar técnicas de análisis de negocio a fin de mejorar su ventaja competitiva mediante
una adecuada definición, gestión y control de los requisitos.
Las actividades de análisis de negocio pueden empezar antes de que el proyecto se
comience y el Project manager sea asignado.
El proceso de gestión de requisitos, puede comenzar en la planificación de la cartera
de proyectos, de un programa de proyectos, o con un proyecto concreto.
Recopilar, documentar y gestionar los requisitos de los interesados, tiene lugar en
los procesos de gestión de alcance.
Algunas de las prácticas emergentes relacionadas con la gestión del alcance de pro-
yecto, incluyen pero no se limitan a colaborar con los profesionales de análisis de nego-
cios a fin de:
• Determinar problemas e identificar necesidades de negocio
• Identificar y recomendar soluciones viables para solventar esas necesidades
• Obtener, documentar y gestionar los requisitos de los interesados, para alcanzar
los objetivos de negocio y de proyecto.
• Facilitar la implantación con éxito del producto, proyecto o resultado final del
proyecto.
El proceso finaliza con el cierre de requisitos, que transfiere el producto, servicio o
resultado al receptor final, a fin de medir, monitorizar y mantener beneficios sostenibles
a lo largo del tiempo.
En ocasiones se asignan recursos con experiencia en análisis de negocio para res-
ponsabilizarse de la gestión del análisis de negocio. Estos recursos, deben tener suficiente
experiencia y capacitación.
En estos casos la relación entre Project manager y analista de negocio ha de ser de
colaboración plena. De hecho, la probabilidad de éxito del proyecto se eleva, cuando
cada uno de los roles (Project manager y analista de negocio) entienden mutualmente
sus roles y responsabilidades, que será de gran ayuda para alcanzar los objetivos de pro-
yecto.
Consideraciones para adaptar la gestión (Tailoring considerations)

Ya que cada proyecto es único, el Project manager debe poder adaptar la forma en
que los procesos de gestión del alcance son aplicados. Algunas consideraciones de adap-
tación a tener en cuenta son:
• Gestión de requisitos y conocimiento: ¿Dispone la organización de sistemas
de gestión de requisitos y conocimiento? ¿Qué directrices debería establecer el
Project manager para establecer requisitos que sean reutilizados en el futuro?
• Validación y control: ¿Dispone la organización de políticas, procedimientos,
guías para validación y control?
• Enfoque de desarrollo: ¿utiliza la organización enfoques ágiles en la gestión
de proyectos? ¿El enfoque de desarrollo es iterativo o incremental? ¿se utiliza
enfoque predictivo? ¿Podría ser productivo un enfoque híbrido?
• Gobernanza: ¿Dispone la organización de políticas, procedimientos, guías para
auditoría y gobernanza?
Consideraciones para entornos ágiles o adaptativos (Considerations for agile

and adaptative environments)
En proyectos con requisitos que van evolucionando, en marcos de alto riesgo o con
incertidumbre significativa, con mucha frecuencia el alcance no es entendido al
comienzo del proyecto o evoluciona a lo largo el mismo.
Los enfoques ágiles emplean, a propósito, menos tiempo tratando de definir y apro-
bar el alcance en las fases tempranas del proyecto y emplean más tiempo estableciendo
el proceso para su descubrimiento y refinamiento sobre la marcha del proyecto.
En los enfoques ágiles, intencionadamente, se construyen y revisan prototipos y
versiones, durante la ejecución del proyecto a fin de ir ajustando y refinando los requi-
sitos. Como resultado, el alcance es definido y redefinido a lo largo del proyecto. En
los enfoques ágiles los requisitos componen el Backlog.
Los entregables son desarrollados a través de múltiples iteraciones en las que cuando
el alcance está definido y aprobado para cada iteración, es cuando se aprueba.
El alcance total del proyecto de un proyecto adaptativo será descompuesto en una
serie de requisitos, que denominamos pila o backlog y el trabajo se enfoca totalmente
al desarrollo de los elementos en él incluidos.
En el comienzo de una iteración, el equipo de trabajo determinará cuantos de los
elementos con más prioridad de la lista del backlog, pueden ser desarrollados en la
siguiente iteración. El equivalente a los tres procesos del alcance (recopilar requisitos,
definir el alcance y crear la EDT), se realiza en cada iteración. En cambio en proyectos
predictivos estos procesos se realizan al inicio del proyecto y son actualizados si es nece-
sario, mediante sistema de control integrado de cambios.
En enfoques ágiles el sponsor o representante del cliente, debería estar continua-
mente involucrado en el proyecto, para proporcionar feedback continuo sobre los
entregables que son creados, y para asegurar que el Backlog de producto (Product
Baklog) refleja sus necesidades actuales. Los 2 procesos de monitoreo y control (Con-
trolar el alcance y validar el alcance) se repiten continuamente en cada iteración.
3.3.2. Planificar la gestión del alcance

Una vez abierto el Plan de Dirección de Proyecto, el primer paso a dar es la defi-
nición de cómo se va a definir, planificar el alcance. Estos aspectos se deben recoger en
el Plan de Gestión del Alcance. Si está bien definido, los siguientes pasos –recoger
requisitos, definir el alcance y crear la EDT– se realizarán de forma más coordinada y
eficiente.
Este proceso tiene por objetivo definir cómo, quién y con quién, se va a definir el
alcance del producto y proyecto, se va a controlar y verificar el alcance, se van a evaluar
y aprobar o no los cambios propuestos en el alcance y se van a definir y gestionar los
requisitos del producto o resultado.
Es un proceso que conviene que esté definido, por parte de la organización, como
un proceso estándar que todos los project managers tomarán como base y que cada uno
aplicará y adaptará a las peculiaridades de su proyecto.
En el siguiente esquema vemos su ubicación dentro del área de conocimiento de
alcance y el grupo de procesos de planificación:
En el siguiente esquema se presentan las entradas, técnicas y herramientas y salidas

que se detallarán a continuación:
Como se ha comentado anteriormente ISO21500 no tiene un proceso específico para ela-

borar el Plan de Gestión del Alcance si bien se considera entre las labores a realizar en el proceso
«Elaborar los Planes de Proyecto».
PLANIFICAR LA GESTIÓN DEL ALCANCE (PLAN SCOPE MANA-

GEMENT):
Este proceso tiene por objetivo definir cómo, quién y con quién se va a definir
el alcance del producto y proyecto, se va a controlar y verificar el alcance, se van a
evaluar y aprobar o no los cambios propuestos en el alcance y se van a definir y
gestionar los requisitos del producto o resultado.
ENTRADAS (INPUTS):
Para elaborarlo se tendrán en cuenta el Acta de Constitución –del área de «gestión de la

integración» y que supone el inicio de un proyecto dentro de la organización donde se define
el contexto del proyecto, se incluye una descripción general del proyecto y se recogen los
requisitos de alto nivel del producto–, el Plan de Dirección de Proyecto, que dará criterios
generales que pueden afectar a la Gestión del Alcance, los factores ambientales de la empresa
que puedan condicionar este plan –cultura, estructura, infraestructura…, de la organización–,

las políticas, procesos y procedimientos preestablecidos por la organización y la información
histórica y lecciones aprendidas de otros proyectos.
Acta de Constitución (Project charter)

El Acta de Constitución recoge los requerimientos de alto nivel, una descripción
general del producto y sus características y los principales entregables. Esta información
será la que el project manager utilice para, con las partes interesadas identificadas, pro-
ceder a la recogida de requisitos. Es, por ello, información relevante para planificar cómo
se va a gestionar el alcance.
Plan de Dirección del Proyecto (Project management Plan)

El Plan de Dirección del Proyecto es el plan que recoge e integra el resto de planes.
Si bien el Plan de Gestión del alcance es una entrada para el Plan de Dirección, el Plan
de Dirección es, a su vez, una entrada para el de Gestión del Alcance ya que dará criterios
generales que pueden afectar a la Gestión del Alcance como son los procesos que se van
a realizar y con qué grado de detalle –que dependerá de la novedad, complejidad, dura-
ción..., del proyecto– así como si, por ejemplo, se va a dividir en varias fases –lo que
afectará a la gestión del alcance–.Especialmente podrán ser útiles los siguientes elementos
del Plan:
Plan de Gestión de Calidad (Quality management plan):
La manera en que el alcance de Producto y Proyecto serán gestionados puede estar
influenciado por las políticas de calidad de la organización, metodologías y estándares,
Descripción del ciclo de vida de proyecto (Project life cycle description):
El ciclo de vida del proyecto determina la serie de fases por las que pasa el proyecto
desde su inicio hasta el final
Enfoque de Desarrollo (Development approach):
El enfoque de desarrollo define si se utilizará un enfoque en cascada, iterativo,
adaptativo, ágil o híbrido.

Entre los factores que pueden afectar a la forma de gestionar el alcance están, por
ejemplo, la cultura y estructura organizativa –y las asignaciones de funciones y respon-
sabilidades en el ámbito de la gestión de los proyectos y, más concretamente, el alcance–,
la infraestructura y equipos, las condiciones de mercado...

La forma de gestionar el alcance puede venir definida o influenciada por las políticas
y procedimientos establecidos en la empresa y la información histórica y lecciones
aprendidas sobre cómo definir, planificar, controlar y validar el alcance.
TÉCNICAS Y HERRAMIENTAS (TOOLS AND TECHNIQUES):
Con esta información como base y la experiencia de cómo se ha gestionado el

alcance en proyectos similares, el project manager y su equipo deben mantener reunio-
nes con todas aquellas partes interesadas que tengan algo que decir sobre el alcance del
producto y del proyecto, y acordar la forma concreta en que va a definir y gestionar el
alcance del proyecto.

El project manager podrá recoger la experiencia de expertos (individuos o grupos)
de fuera y/o dentro de la organización con conocimiento o formación en proyectos
previos similares o información de la industria, disciplina o área de aplicación que será
muy valiosa para ayudarle a establecer cuál es la mejor manera de definir, planificar,
validar y controlar el alcance.
Análisis de datos (Data Analysis)

Una técnica de análisis de datos, puede ser el análisis de alternativas... Hay múltiples
formas de recopilar requisitos, elaborar el alcance del producto y proyecto, crear el
producto, validar y controlar el alcance, por lo que distintas alternativas podrán ser
evaluadas.
Con la información de las entradas como base y la experiencia de cómo se ha ges-
tionado el alcance en proyectos similares, el project manager y su equipo deben man-
tener reuniones con todas aquellas partes interesadas que tengan algo que decir sobre el
alcance del producto y del proyecto, y acordar la forma concreta en que se va a definir
y gestionar el alcance del proyecto.
SALIDAS (OUTPUTS):
El Plan de Gestión del Alcance (Scope management plan)

El Plan de Gestión del Alcance describirá cómo se va a definir, desarrollar, moni-
torizar, controlar y validar el alcance. Contendrá los procedimientos para recoger los
requisitos, preparar un Enunciado del Alcance detallado, preparar la EDT a partir del
anterior, mantener y actualizar cambios aprobados en la EDT, obtener la aprobación
formal de los entregables por parte del cliente y controlar cómo se procesan las pro-
puestas de cambio al alcance del proyecto.
Algunos de los componentes que el plan de gestión del alcance puede incorporar:
Procesos para preparar el enunciado del alcance del proyecto.
• Procesos que permiten la creación de la EDT del enunciado del alcance del
proyecto detallado.
• Procesos que establecen como la línea base del alcance será aprobada y mante-
nida.
• Procesos que especifican la aceptación formal de los entregables de proyecto
El Plan de Gestión del Alcance, una vez incorporado al Plan de Dirección de Pro-
yecto, será entrada a su vez para los procesos de:
– Recopilar requisitos.
– Definir el alcance.
– Crear la EDT
El Plan de Gestión de Requisitos (Requirements management plan)

El Plan de Gestión de Requisitos que describirá cómo se van a definir, analizar,
documentar y gestionar los requisitos del proyecto.
Debe definir:
• Cómo los requisitos de las actividades serán planificados, monitorizados, y
reportados.
• Actividades de Gestión de la configuración: Quién y cómo planificará, seguirá

y reportará las actividades asociadas a los requisitos –cómo se iniciarán los cam-
bios en el producto, cómo se analizarán su impacto, cómo y quién aprobará los
cambios y supervisará su implementación–.
• Cómo se priorizarán los requisitos.
• Qué métricas de producto se utilizarán para asegurar que los requisitos se cum-
plen.
• Estructura de trazabilidad que refleja los atributos de los requisitos capturados
en la matriz de trazabilidad.
El Plan de Gestión de Requisitos, una vez incorporado al Plan de Dirección de
Proyecto, será entrada a su vez para el proceso de Recogida de requisitos.
3.3.3. Recopilar requisitos

En este proceso se definen y documentan las necesidades y expectativas de las partes
interesadas y se traducen a requisitos medibles que al cumplirlos permitan alcanzar los
objetivos del proyecto. El éxito del proyecto está muy directamente relacionado con el
cuidado que se tome en la planificación y recogida de requisitos del proyecto, en general,
y del producto, servicio o resultado, en particular.
Los requisitos incluyen condiciones o capacidades que debe cumplir el proyecto o
que deben estar presentes en el producto, servicio o resultado para satisfacer lo estable-
cido por contrato o por una especificación. Los requisitos incluyen también las necesi-
dades y expectativas cuantificadas y documentadas del sponsor, cliente y otras partes
interesadas.
El reto es descubrir los requisitos –no siempre están claros y explícitos–, analizarlos
y registrarlos con suficiente detalle para ser incluidos en el alcance, poder utilizarlos en
la elaboración de la EDT y poder ser medidos una vez comience su ejecución.
En este proceso se definen y documentan, por tanto, las necesidades, deseos y
expectativas del patrocinador (sponsor), del cliente (client) y demás interesados (sta-
keholders) para poder cumplir así los objetivos del proyecto. En especial se requiere un
esfuerzo importante de definición y gestión de las expectativas del cliente sin descuidar
la del resto de interesados.
En todos los casos, sea la técnica o herramienta que se elija, será clave equilibrar los
intereses de todas las partes interesadas para lo que el project manager apoyado y res-
paldado por el patrocinador debe:
• Identificar las partes interesadas y dejar bien claros los requerimientos del pro-
ducto y proyecto.
• Identificar los intereses confluyentes y buscar soluciones que satisfagan a todas
las partes.
• Priorizar los requerimientos según los objetivos del proyecto y estratégicos de
la empresa teniendo siempre claro que, en caso de duda, los que prevalecen son
los del cliente.
Los criterios para aceptar o rechazar un trabajo en el proyecto serán, por este orden:
• Que satisfaga la necesidad que dio lugar al proyecto, si no, se rechaza.
• Que esté incluido dentro del Acta de Constitución, si no, se rechaza.
• Que pueda integrarse en el Enunciado del alcance del proyecto.
• Que no sea incompatible con restricciones impuestas al proyecto.
La ubicación de este proceso dentro de su área de conocimiento y los grupos de
procesos se refleja en la siguiente figura:
En ocasiones, la recogida de requerimientos no se realiza dentro del proyecto, sino

que es una entrada externa que, en forma de proyecto constructivo o especificaciones
técnicas, incluye ya los requerimientos del producto. A efectos formativos en este docu-
mento, consideraremos que los requisitos se definen dentro del proyecto.

Los requisitos de alto nivel han sido ya establecidos en el inicio del proyecto en el
Acta de Constitución. En este proceso se afinarán, completarán y convertirán en reque-
rimientos, cuyo éxito sea medible, y en entregables, cuya inspección y aceptación, de
acuerdo a ellos, sea inequívoca.
Los requerimientos del producto son lo que las partes interesadas necesitan que
cumpla el producto o servicio, porque resuelven unos problemas o alcanzan unos obje-
tivos. Pueden referirse a:
• Cómo debe funcionar el sistema (opciones de seguridad y definición de perfiles).
• Funcionalidades que debe tener el producto (compatibilidad con determinado
sistema operativo).
• Calidad de sus componentes (utilizando determinado material aislante).
• Procesos de negocio (que permita realizar un seguimiento y aprobación digital
de facturas).
• Procesos de seguridad, salud y control de riesgos (que cumpla una determinada

normativa, no necesariamente obligatoria).
Este proceso es crítico ya que un requerimiento no identificado y no incluido puede
llevar al traste con el proyecto y que, llegado el momento de la entrega, el cliente no
lo acepte con las consiguientes consecuencias económicas y de pérdida de la confianza
de éste.
En este esquema se presenta, de forma resumida y esquemática, las partes de que
consta el proceso de recopilación de requisitos, sus entradas (inputs), las técnicas y
herramientas (techniques and tools) utilizadas y las salidas (outputs) del proceso que, a
su vez, alimentarán otros procesos posteriores.
Como se ha comentado anteriormente ISO21500 no tiene un proceso específico para recoger

los requisitos si bien se considera entre las labores a realizar en el proceso «Definir el alcance».
RECOPILAR REQUISITOS (COLLECT REQUIREMENTS):

En este proceso se definen, documentan y gestionan las necesidades y expectativas
de las partes interesadas y se traducen a requisitos medibles que al cumplirlos permitan

alcanzar los objetivos del proyecto.
El beneficio clave de este proceso es que proporciona la base para definir el alcance
del producto y el alcance del proyecto.
ENTRADAS (INPUTS):
Para realizar esta recogida de requisitos se necesitarán el Acta de Constitución –

donde se han definido los requisitos de alto nivel, y el Plan de Dirección de Proyecto,
que incorporará : el Plan de Gestión del Alcance –resultado del proceso anterior–, que
indica cómo gestionar el alcance; el Plan de Gestión de Requisitos –también resultado
del proceso anterior–, que indica cómo proceder en la gestión de requisitos; el Plan de
Gestión de Interesados y su Registro –donde se han recogido las necesidades y expec-
tativas de cada una de ellas–. También se utilizarán Documentos de proyecto como p.ej.
Registro de Asunciones, registro de lecciones aprendidas, y registro de riesgos, Docu-
mentos de negocio, como el caso de negocio, los contratos, y los Factores ambientales
de la empresa y Activos de los Procesos de la organización.

Es un documento que autoriza formalmente el proyecto, concede autoridad al pro-
ject manager y define a alto nivel el alcance aprobado del proyecto y los requisitos de
alto nivel que serán utilizados para desarrollar requisitos detallados.
Plan de Dirección de Proyecto (Project Management Plan)

Del Plan de Dirección de Proyecto, se consultarán principalmente:
Plan de Gestión del Alcance (Scope management plan)

Este plan indica a los miembros del equipo de proyecto cómo deben determinar el
alcance del proyecto y, dentro de él, el tipo de requisitos que deben recoger y cómo
recogerlos.
Plan de Gestión de Requisitos (Requirements management plan)

Este plan define cómo se van a gestionar los requisitos a lo largo de la vida del
proyecto garantizando su trazabilidad, integrando las propuestas de cambios en el pro-
ceso general del proyecto, para que, al final, el producto tenga todos y sólo los requisitos
establecidos en el proyecto.
Plan de Gestión de los Interesados (Stakeholders management plan)

Este plan define cómo se van a gestionar las necesidades y expectativas de las partes
interesadas muy especialmente en el proceso de recoger requisitos. La importancia de
una determinada parte interesada será clave para definir la prioridad de sus requisitos
respecto a los de otras partes interesadas.
Documentos de Proyecto (Project Documents)

Registro de Asunciones (Assumptions log)
El registro de asunciones identifica asunciones sobre el producto, proyecto, entorno,
interesados, y otros factores que pueden influir en los requisitos
Registro de Lecciones Aprendidas (Lessons learned register)

El registro de lecciones aprendidas se puede utilizar para proporcionar información
sobre técnicas de recopilación de requisitos efectivas especialmente en proyectos que
están utilizando una metodología de desarrollo de producto iterativa o adaptativa
Registro de Interesados (Stakeholders register)

Es la lista de las personas/organizaciones que pueden proporcionar información
sobre los requisitos. Por tanto, son aquellas con los que el project manager tendrá que
hablar para identificar los requisitos y expectativas respecto al producto y el proyecto,
bien porque vayan a verse afectados, porque deban entregar o recibir información, o
bien porque deban estar informados.
Documentos de Negocio (Business Documents)

Los documentos de negocio pueden influir en el proceso de recopilación de requi-
sitos, ya que en ellos se pueden describir criterios requeridos, deseados y opcionales para
alcanzar las necesidades de negocio.
Acuerdos (Agreements)
Los acuerdos previos a la ejecución de proyecto pueden contener definiciones de
requisitos de proyecto y de producto, que debemos cumplir.
Factores ambientales de la empresa (Enterprise enviromental factors)

Algunos factores ambientales que pueden influir en la recopilación de requisitos
pueden incluir:
• Cultura de la organización.
• Infraestructuras.
• Administración de personal.
• Condiciones de mercado
Activos de los procesos de la organización (Organizational Process Assets)

Algunos activos de los procesos de la organización que pueden influir en la reco-
pilación de requisitos pueden ser:

• Condiciones de mercado.
Con toda esa información, el project manager y su equipo podrán mantener entre-
vistas, organizar grupos de trabajo específicos o transversales, utilizar técnicas como los
mapas mentales, elaborar cuestionarios y encuestas, proponer la elaboración de proto-
tipos, analizar todos los documentos relevantes..., para tratar de realizar una identifica-
ción completa de los requisitos del producto, servicio o resultado y del proyecto.
Juicio de expertos (Expert Judgement)

La utilización del juicio de expertos debería ser considerado de individuos o grupos
con conocimiento o formación específica en los siguientes temas:
• Análisis de negocio.
• Elicitación de requisitos.
• Análisis de requisitos.
• Documentación de requisitos.
• Requisitos de proyecto en proyectos similares.
• Técnicas de diagramación.
• Facilitación.
• Resolución de conflictos.

Tormenta de ideas (Brainstorming)
Tormenta de ideas es una técnica que puede ser utilizada para generar y recopilar
múltiples ideas relativas a requisitos del proyecto o del producto
Entrevistas (Interviews)
El project manager entrevista a las partes interesadas en un diálogo directo y prefe-
rentemente individualizado para así identificar sus requerimientos para un determinado
elemento del producto o del proyecto en general. Estos encuentros pueden ser llevados
a cabo vía videoconferencia, teléfono, presencial…
Grupos de opinión (Focus Group)
En este caso un grupo determinado de partes interesadas o expertos en una materia
comparten y discuten sobre sus ideas y puntos de vista en relación al proyecto, siendo
moderado por un agente externo que puede ser el project manager.
Cuestionarios y encuestas (Questionnaires and surveys)
Se usan sobre todo para grupos grandes donde además puede ser conveniente realizar
análisis estadísticos.
El project manager, o quien haga de moderador y coordinador, elabora cuestionarios
que ayuden a identificar requerimientos por parte de los participantes.
Un ejemplo: preguntar a los clientes, potenciales compradores de un nuevo teléfono
móvil, sobre las funcionalidades que más agradecerían que tuviera el nuevo modelo que
va a sacar la compañía.
Benchmarking (Benchmarking)
El benchmarking es un proceso sistemático y continuo para evaluar los productos,
servicios y procesos de trabajo de las organizaciones reconocidas como las que aplican
mejores prácticas.
Podemos identificar tres tipos de benchmarking:
• Interno: Se suele dar en grandes empresas formadas por numerosos departa-
mentos y/o divisiones, en las que es muy común comparar los niveles alcanzados
dentro de la misma organización.
• Competitivo: Se utiliza cuando hay una competencia agresiva, comparando

algunos aspectos con los competidores más directos, o con los líderes del mer-
cado, sobre un cierto producto.
• Funcional: Consiste en compararse con empresas que no pertenecen a tu misma
industria; con este consigues la ventaja de obtener la información necesaria al
no ser competidor de la empresa.

Las técnicas de análisis de datos pueden ser utilizadas para este proceso. Por ejemplo,
incluyen el análisis de documentos.
Realizar el análisis de documentos consiste en revisar y evaluar cualquier informa-
ción importante que se encuentre en la documentación. En este proceso el análisis de
documentos se utiliza para elicitar requisitos por medio del análisis de la documentación
existente y para identificar información importante de cara a la identificación de los
requisitos.
Una fuente de requerimientos serán los documentos de proyecto como el contrato,
el caso de negocio, la documentación de requisitos de otros proyectos... y otros como
registros de incidencias, políticas, procedimientos, documentación sobre legislación y
reglamentaciones…
Algunos otros ejemplos de documentos:
• Acuerdos.
• Planes de negocio.
• Procesos de negocios
• Repositorios de reglas de negocio.
• Flujos de procesos actuales.
• Bibliografía de marketing.
• Registro de problemas e incidencias.
• Procedimientos y políticas.
• Documentación regulatoria leyes códigos ordenanzas.
• Ofertas para licitaciones.
• Casos de uso.
Toma de decisiones (Decision making)

Votación (Voting)
La votación es una técnica de toma de decisiones para obtener una alternativa elegida
dentro del conjunto de las alternativas posibles evaluadas. Éstas técnicas pueden ser uti-
lizadas para generar, clasificar, y priorizar requerimientos del producto. Además, todos
los esfuerzos para identificar requerimientos de grupos de personas suelen provocar
conflictos más o menos importantes. Tanto en uno como en otro caso, se pueden tomar
las decisiones:
• Unanimidad: implica que todo el grupo tiene que estar de acuerdo.

• Mayoría: una decisión es alcanzaba cuando se tiene un apoyo de más del 50%
de los miembros del grupo.
• Pluralidad: una decisión es tomada cuando el bloque más grande lo decide,
incluso aunque la mayoría no se haya alcanzado. Se utiliza este método nor-
malmente cuando hay más de dos opciones
• Autocracia: un individuo toma la decisión por el grupo. Un caso de este tipo
de toma de decisiones puede ser una decisión directamente tomada por el
cliente.
En cualquier caso, la opción más votada debe ser respaldada por todos los compo-
nentes del grupo y solidariamente asumida como propia.
Análisis de decisión multicriterio (Multicriteria decision analysis)
Una técnica que utiliza una matriz de decisión para proporcionar un enfoque sis-
temático y analítico para tomar decisiones en base a criterios como por ejemplo niveles
de riesgo, incertidumbre y validación a fin de evaluar y puntuar distintas ideas o alter-
nativas.
Representación de ideas (Data representation)

Diagramas de afinidad (Affinity Diagrams)
Los diagramas de afinidad (affinity diagrams) que tratan de agrupar las ideas surgidas
de acuerdo a algún tipo de criterio (similitud, riesgo…). En el ejemplo siguiente, sur-
gieron diferentes aspectos a tener en cuenta en un proyecto de una instalación eólica y
se agruparon por temas o áreas de responsabilidad:
Mapas mentales (Mind maps)

Los mapas mentales (mind maps) –diagramas en los que conforme salen ideas se van
plasmando y permite identificar relaciones entre ellas–. Cuando se ha acabado el trabajo
sobre una idea suele ayudar crear un mapa en el que se vean las ideas que han surgido,
cómo se ha llegado a ellas y tratar de agruparlas por algún criterio. La siguiente figura
sería un mapa mental simplificado:
Habilidades interpersonales y de equipo (Interpersonal and Team skills)

Técnicas de grupo nominal (Nominal group technique)
Las técnicas del grupo nominal (nominal group techniques), mediante un proceso
de votación, se usan para priorizar o jerarquizar las ideas que hayan surgido en otros
ejercicios (p.ej. tormenta de ideas).

La técnica de grupo nominal es una forma estructurada de Brainstorming consistente
en cuatro pasos:
• Una cuestión o problema es planteado al grupo. Cada persona genera de forma
individual y en silencio sus ideas y las anota.
• El moderador anota las ideas en una pizarra o flip chart hasta que todas las ideas
se han registrado.
• Cada idea anotada es discutida hasta que todos los miembros del grupo tienen
un claro entendimiento.
• Cada uno vota de forma privada para priorizar las ideas, usualmente utilizando
una escala de 1 a 5, siendo 1 el más bajo y 5 el más alto. La votación puede
llevarse a cabo en varias rondas para reducir ideas y enfocar sobre las mejores.
Después de cada ronda los votos son contados y las ideas con una puntuación
más alta son seleccionadas.
Observación (Observation/conversation)
Con una técnica similar al comprador invisible (invisible buyer) –una persona va a
comprar a una tienda y observa y anota cómo le atienden–, se observa desde el anoni-
mato (job shadowing) cómo trabajan los empleados para tratar de identificar ineficien-
cias, áreas de mejora, riesgos…, o se propone que un «observador participante» se ponga
a hacer el trabajo para experimentar cómo se hace y descubrir requisitos o puntos de
mejora.
Es particularmente útil cuando las personas que utilizan el producto tienen dificul-
tades o resistencia para articular sus requisitos
Facilitación (Facilitation)
Son sesiones dirigidas a reunir a los interesados para definir los requisitos del pro-
ducto. Por ejemplo, reuniendo diferentes partes interesadas procedentes de diferentes
áreas de conocimiento (marketing, ingeniería, financiero, innovación…) de la empresa,
a fin de que:
• Hablen e intercambien ideas sobre el producto.
• Traten de buscar consenso en relación a los requerimientos.
• En ocasiones, los clasifiquen y ordenen por prioridad.
• Se establezcan acciones y objetivos para cumplirlos.
Algunos ejemplos:
– Joint appllication design (JAD): Se utilizan en la industria del software. Estas
sesiones se enfocan en juntar a expertos en la materia del tema de negocio y al
equipo de desarrollo para capturar los requerimientos y mejorar el proceso de
desarrollo de software
– Despliegue de función de Calidad (QFD. Es una técnica utilizada en la industria
de manufactura. Que ayuda a determinar características esenciales para el desa-
rrollo de un nuevo producto. Las necesidades del cliente (Voice of customer –

VOC) son ordenadas y priorizadas, y se ponen las metas para alcanzarlas.
– Historias de Usuario (US-User stories). Las historias de usuario son una des-
cripción textual de una funcionalidad requerida.
Una historia de usuario tiene 3 partes:
El rol (role) que es quien se beneficia de la característica o funcionalidad
Lo que el interesado necesita realizar (goal)
Y el beneficio al interesado (motivation)
Ejemplo de Historia de Usuario:
Como: lector del blog
Quiero: poder añadir comentarios a las entradas y recibir alertas cuando otros hagan
comentarios
Para poder: mantenerme en contacto con el resto de usuarios del blog
Diagramas de contexto (Context diagrams)

El diagrama de contexto es un caso especial del diagrama de flujo de datos, en donde
una sola burbuja representa todo el sistema.
El diagrama de contexto muestra a través de flujos de datos las interacciones exis-
tentes entre los agentes externos y el sistema, sin describir en ningún momento la
estructura del sistema de información.
En este tipo de diagrama, el sistema de información debe representarse como un
único proceso de muy alto nivel, con entradas y salidas hacia los agentes externos que
lo limitan, de forma equivalente a una caja negra.
Teniendo en cuenta que este diagrama debe de ser comprensible, no es posible
representar todos los flujos de datos del sistema en él, sino más bien debe representarse
en él una visión general del sistema desde la perspectiva de los propietarios de sistemas
siguiendo dos lineamientos básicos:
• Representar únicamente los flujos de datos que tengan algo que ver con el
objetivo principal del sistema.
• Utilizar flujos de datos compuestos que representen a aquellos que sean similares.
Dentro de éste diagrama se enfatizan varias características importantes del sistema:
• Las personas, organizaciones y sistemas con los que se comunica el sistema. Son
conocidos como terminadores.
• Los datos que el sistema recibe del mundo exterior y que deben procesarse de
alguna forma.
• Los datos producidos por el sistema y que se enviarán al exterior.
• Los almacenes de datos que el sistema comparte con los terminadores.
• La frontera entre el sistema y el resto del mundo.
El siguiente esquema presenta un buen ejemplo:
Prototipos (Prototypes)
Se crea un modelo operativo del producto esperado antes de construirlo para que
los interesados puedan experimentar y hacerse una idea a escala del resultado final.
Si bien es una herramienta más cara y que puede llevar más tiempo, el prototipo
pretende que el cliente o las partes interesadas vean una versión beta de su producto o
servicio para, sobre ella, ir detectando mejoras, requerimientos nuevos que puede suge-
rirle su uso… En definitiva, sigue el concepto de elaboración gradual (progressive ela-
boration) al usar ciclos iterativos.
Ver cómo se comporta el cliente o el usuario final con un prototipo o con un
producto similar puede dar muchas ideas sobre el uso que se le da, las funcionalidades
que se utilizan mucho y las que apenas se utilizan.
Es una herramienta muy útil si el proyecto se está desarrollando con técnicas itera-
tivas.
Estos métodos son muy usados en el desarrollo de proyectos informáticos, muy
especialmente si se utilizan herramientas y marcos de desarrollo ágiles, donde los reque-
rimientos del cliente se van definiendo conforme avanza el producto y con una siste-
mática que implica una relación estrecha y fluida entre cliente y equipo de proyecto.
Otro ejemplo puede de técnicas para realizar prototipos puede ser la técnica de
Storyboarding, en las que se muestra una secuencia de navegación a través de una serie
de imágenes o ilustraciones.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtendrá:
Documentación de requisitos (Requirements documentation)

La documentación de requisitos recogerá todos los requisitos identificados, que sean
medibles, comprobables, trazables, completos, consistentes y aceptados por las partes
interesadas clave; su impacto en otras áreas de la organización, en otras entidades internas
o externas a la organización; y los supuestos y restricciones detrás de cada requisito.
Estos requisitos pueden ser, de acuerdo a PMBOK® Guide:
• Requisitos de negocio como los objetivos de trazabilidad de los objetivos de
la organización, los principios que guían la organización…
• Requisitos de interesados como el impacto en otras áreas de la organización,
el impacto en otras entidades dentro y fuera de la organización o los requisitos
de comunicación y reporte de los interesados.
• Requisitos de solución como las funcionales y no funcionales, los de cum-
plimiento de estándares, los de soporte y formación, los de calidad, los de
reporte…
• Requisitos de transición como capacidades temporales, migración, puesta en
marcha, etc.
• Requisitos del proyecto como los niveles de servicio, desempeño, seguridad,
etc.
• Requisitos de calidad como tests, certificaciones, validaciones, etc.
• Restricciones, dependencias e hipótesis relativas a los requisitos.
Esta documentación de requisitos se utilizará como entrada en procesos de alcance

– los procesos de definir el alcance y elaborar la EDT, de adquisiciones – los de planificar
la gestión de las compras (área de conocimiento de gestión de las adquisiciones), si parte
del trabajo se decide externalizar– y parar planificar la gestión de la calidad (área de
conocimiento de gestión de la calidad).
Todos los requisitos recogidos con cualquiera de los métodos anteriores –cada pro-
ject manager, en función de las características de la compañía y del proyecto, elegirá el
o los más apropiados– se deben documentar, siendo esta documentación una salida del
proceso.
Documento de Requisitos del Proyecto (Project requirements document)

– Antecedentes/Resumen del proyecto
– Impacto en la Organización
– Necesidad comercial
– Objetivos de la empresa y el proyecto
Requerimientos Funcionales (Functional requirements)
Nombre 7896-S
Síntesis Posibilidad de que jueguen hasta 4 jugadores
Justificación Es un juego con potencial para uso familiar
El juego debe permitir la selección del número de jugadores, así como el hán-
Requerimiento
dicap de cada uno
Requerimientos NO funcionales (Non functional requierements)
Nombre 456-O Funcionamiento más rápido
Síntesis Se desea que la visualización gráfica sea mejor
Justificación Los usuarios se quejan de que el juego va lento
La velocidad de carga y descarga de nuevas ventanas no debe tardar más de 2

Requerimiento
segundos
Requerimientos de Calidad y Criterios de aceptación (Acceptance criteria)
Requisitos de recursos principales (Key resources)
Supuestos (assumptions) –si no se cumplen son riesgos–
Restricciones del proyecto (Restrictions)

Fases/Entregables (deliverables) del proyecto (lo que se entrega al cliente y lo que el
entrega a la compañía)
Hitos (milestones) principales
Tabla de inclusiones (lo que sí incluye el proyecto) y exclusiones (lo que no está
incluido)
Otros aspectos como el impacto sobre otros proyectos, sobre otras entidades, requi-
sitos de apoyo y capacitación
Este proceso y esta documentación deben garantizar que los requisitos están clara-
mente definidos y no son ambiguos.
Por ello, se debe preguntar al cliente qué va a hacerle decidir que el producto es
aceptable, cómo define que el producto sea un éxito. Por una parte, estaremos seguros
de que hemos entendido el requerimiento de la parte interesada y, por otra, el project
manager se asegura que el trabajo que haga será aceptado. Un ejemplo de este docu-
mento podría ser el siguiente:
Otra forma de representarlos es mediante una tabla de requisitos con un esquema
como el siguiente:
Parte Intere- Criterio de

Requisito Justificación Prioridad
sada aceptación
Matriz de trazabilidad de requisitos (Requirements traceability matrix)

Una de las cosas que no debe pasar nunca en un proyecto es que, durante la fase de
ejecución y los sucesivos cambios que se puedan producir, se pierda algún requerimiento
o no se tenga la documentación descriptiva que aclare sus razones y alcance. La matriz
de trazabilidad de requisitos trata de evitar este hecho siguiendo la traza de toda esa
información y analizando los requerimientos cuando hay cambios en el alcance del
producto o el proyecto.
La matriz de trazabilidad de requisitos relaciona cada requisito con su origen, la parte
interesada que lo solicitó, su justificación, el objetivo de negocio relacionado, el paquete
de trabajo asociado, el diseño del producto, el control de calidad... Entre los atributos
que suelen incorporarse son un identificador único, la descripción del requisito, el pro-
pietario, la prioridad, la versión, el estado (activo, cancelado, añadido, aprobado..). y la
fecha de cierre.
Esta matriz nos ayudará a asegurarnos de que cada requisito tiene un valor de negocio
identificado, que, en caso de tener que modificarlo, tenemos claro el origen y razón de
ser del mismo y podemos seguirlo a lo largo de la vida del proyecto para que, al final,
todos los requisitos aprobados, y solo los aprobados, estén incorporados al producto o
resultado. Esta matriz de trazabilidad se utilizará como entrada para los procesos de
controlar el alcance y validar el alcance.
Esta matriz suele ser una tabla con la siguiente información:
• Un número de código del requerimiento.
• La descripción del requisito.
• El origen y la razón del mismo.
• Quién es el responsable del mismo.
• La prioridad.
• El historial de cambios.
• La versión vigente.
• El estado actual.
• La fecha prevista de cumplimiento.
Otro ejemplo sería el de la siguiente tabla:
Objetivos Compo- Diseño

Requi- Necesidad Actividad
Código de pro- nente de la de Pro-
sito de Negocio de Calidad
yecto EDT ducto
Los aspectos que se puede trazar pueden ser relativos a las necesidades, los objetivos
y alcance del producto, diseño y desarrollo del producto y estrategias y escenarios de
prueba.
El project manager suele designar un responsable de este tema dentro del equipo.
3.3.4. Definir el alcance

Una vez identificados los requisitos del producto, servicio o resultado y del proyecto,
este proceso tiene por objetivo elaborar una descripción detallada del producto y del
proyecto y, muy especialmente, una clarificación de sus límites, lo que estará incluido
y lo que no.
Para ello, el project manager y su equipo deben evaluar las soluciones alternativas
posibles y proponer aquella que, cumpliendo con los requisitos de producto y proyecto,
cumple las restricciones establecidas al proyecto.
En este proceso se seleccionan –puede no ser posible incorporar todas– las caracte-
rísticas/requisitos del proceso anterior y se elabora una descripción detallada del pro-
ducto o resultado y del proyecto a ejecutar. La preparación del Enunciado del alcance
del proyecto detallado es crítica para el éxito del proyecto y se basa en los entregables
principales definidos, las restricciones y supuestos definidos y documentados en la fase
de inicio –recogidos en el Acta de Constitución–.
Durante este proceso, por tanto, se define qué está y qué no está incluido en el
proyecto y sus entregables. Utiliza:
• Las salidas del proceso Planificar la Gestión del Alcance.
• Los requisitos recogidos.
• El Acta de Constitución.
• Otra información que se haya ido añadiendo sobre hipótesis de partida y limi-
taciones.
Con todo ello, se define finalmente el alcance del producto (product scope) y del
proyecto (project scope statement).

Como ocurre con otros aspectos, el alcance será casi con toda probabilidad cam-
biante a lo largo del proyecto, ya sea por:
• la nueva introducción de requisitos por parte del cliente,
• por restricciones no previstas de personal,
• por eventos de riesgo que se hacen realidad,
• por cambios en las expectativas de los interesados, o
• por otras razones.
Por ello, se producirán cambios en la triple restricción tiempo, coste y alcance, que
afectará al resto de documentos del proyecto.
Por ello, el alcance se definirá al inicio del proyecto o fase, pero se revisará cada vez
que se produzca un evento, un cambio… que lo altere, manteniendo así un proceso
iterativo.
Este proceso es clave en el proyecto, como todos los que se tratan en este capítulo
ya que condicionan todos los demás –duración, costes, recursos…–. Si no se define y
gestiona bien el alcance, el producto final puede tener requisitos que ya no se desean y,
al contrario, no tener otros que a lo largo del proyecto han sido solicitados y aprobados.
La ubicación de este proceso dentro de su área de conocimiento y en el grupo de
procesos general es el siguiente:
El siguiente esquema muestra las entradas (inputs), técnicas y herramientas (techni-

ques and tools) y salidas (outputs) del proceso concreto:
En ISO21500 se propone el proceso «Definir el alcance (Define scope)» cuyo objetivo es

definir claramente el alcance del proyecto, lo que incluye definir sus objetivos, entregables,
requisitos y límites mediante la descripción clara del resultado final esperado.
El alcance debe dejar claro en qué manera contribuye el proyecto a los objetivos de negocio
y/o estratégicos de la organización que lo promueve. Se utilizará como base para futuras deci-
siones así como para comunicar la importancia del proyecto y sus beneficios a las diferentes partes
intervinientes.
Entradas Salidas
Acta de Constitución Enunciado del Alcance
Cambios aprobados Requisitos
Observamos cómo aunque en ISO21500 no hay un proceso específico como el de «Reco-

pilar requisitos» de PMBOK, estas actividades se realizan en este proceso de «Definir el
alcance», razón por la cual las dos salidas son definir el Enunciado del Alcance (del proyecto)
y los requisitos.
DEFINIR EL ALCANCE (DEFINE SCOPE):

Es el proceso en el que se elabora una descripción detallada del proyecto y el
producto.
El beneficio clave de este proceso es que describe los límites y criterios de aceptación,
del producto, servicio o resultado final.
ENTRADAS (INPUTS):
Para definir el alcance se utilizan el acta de constitución –que incluye una descrip-
ción general del producto y sus características y los criterios de aprobación del proyecto-,
el Plan de Dirección de Proyecto, en particular el plan de gestión del alcance –que define
cómo definir el alcance del producto y servicio- y algunos documentos de proyecto

como por ejemplo la documentación de requisitos –resultado del proceso anterior y de
la que se seleccionan las características que se incluirán en el alcance del producto-, el
registro de riesgos, y el registro de asunciones. Por último, también se utilizarán los
factores ambientales de la empresa –Cultura, organización, etc. – y políticas, procesos
y plantillas predefinidas por la organización, ficheros de proyectos anteriores similares y
lecciones aprendidas de proyectos o fases previas.

Como en otros casos, indicará las necesidades del negocio, quién es el patrocinador
o cliente, quienes son las partes interesadas y una descripción general del proyecto. A
efecto de la definición del alcance: proporciona la descripción a alto nivel del proyecto,
las características del producto y los requisitos de aprobación.


Es precisamente el documento que indica cómo recoger los requisitos, cómo definir
el alcance y elaborar la EDT. Además, se establece como se definirá, validará y controlará
el alcance.

El registro de asunciones identifica asunciones y restricciones sobre el producto,
proyecto, entorno, interesados, y otros factores que pueden influir en el alcance de
producto y proyecto
Documentación de requisitos (Requirements documents)

Salida del proceso anterior, recoge todos los requisitos del producto final que debe-
mos tener en cuenta a la hora de definir el alcance y que, además, han sido consensuadas
con todas las partes interesadas.
Registro de Riesgos (Risk register)

El registro de contiene estrategias de respuesta que pueden afectar al alcance del
proyecto tales como por ejemplo reducir o cambiar el alcance del proyecto y producto,
para evitar o para mitigar un riesgo.
Factores ambientales de la empresa (Enterprise enviromental factors)

Algunos factores ambientales que pueden influir en el proceso de definición del

alcance pueden incluir:
• Condiciones de mercado

Donde se podrán encontrar –si existen en la organización– procedimientos, ins-
trucciones, plantillas, formularios… así como ficheros de proyectos anteriores, y regis-
tros de lecciones aprendidas de fases o proyectos previos, para realizar la definición del
alcance con el conocimiento corporativo de la compañía y adaptarlo a las particulari-
dades del proyecto.
El project manager, tomando como base la información anterior, se reunirá con el

cliente, otras unidades de la organización, expertos en la materia..., analizará el producto
solicitado utilizando diferentes técnicas –desglose del producto, el análisis de sistemas,
el análisis de requisitos, ingeniería de valor...– para traducir las descripciones del pro-
ducto a entregables tangibles, estudiará diferentes alternativas de ejecutar el proyecto, u
organizará talleres de trabajo transversales con el objetivo final de definir adecuadamente
el alcance del proyecto.
Juicios de expertos (Experts judgement)

Como en otros casos, un experto en el sector o tecnología en la que se desarrolla el
proyecto puede ser de gran ayuda. Estos expertos podrán proceder de otras unidades de
la organización, consultores externos, partes interesadas, asociaciones técnicas y profe-
sionales, a fin de que nos ayuden en base al conocimiento o formación que disponen
con proyectos similares.

Generación de Alternativas (Alternatives Analysis)
Lo que busca esta herramienta son diferentes maneras de realizar el mismo trabajo
que puedan llegar a ser más eficientes. Pueden referirse a una tarea concreta o a un área
de trabajo: podemos programar un módulo de programación, modificar uno existente
para el uso concreto actual o contratar un software específico.
Se podrán utilizar técnicas como la tormenta de ideas (brainstorming), el pensa-
miento lateral (lateral thinking)… que permitan generar diferentes soluciones para
afrontar el problema.

Análisis de decisión multicriterio (Multicriteria decision analysis)
Una técnica que utiliza una matriz de decisión para proporcionar un enfoque sis-
temático y analítico para tomar decisiones en base a criterios como por ejemplo requi-
sitos, plazos, presupuesto, y recursos en orden de refinar el alcance del producto y del
proyecto.
Habilidades interpersonales y de equipo (Interpersonal and Team skills)

Son sesiones dirigidas a reunir a los interesados para trabajar con interesados clave
que tienen diversidad de expectativas o campos de experiencia. El objetivo es alcanzar
un entendimiento común y global de los entregables del proyecto y conocer los límites
de producto y proyecto.
Al llevar a cabo estos talleres con las partes interesadas, se trata de que el alcance
finalmente recogido y definido incluya sus necesidades, requerimientos y expectativas,
identificándolas y documentándolas para traducirlas en trabajos concretos que el equipo
de proyecto va a tener que realizar para entregar el producto o servicio solicitado.
Durante este trabajo será clave, aunque difícil, incluir en el alcance objetivos cuan-
tificables, medibles, que hagan más fácil ver si se han cumplido o no, si el producto está
correcto o no –sobre todo en lo que se refiere a las expectativas, menos precisas, de las
partes interesadas–.
Análisis del producto (Product analysis)

Esta herramienta tiene por objetivo analizar los objetivos y describir el producto tal
y como ha sido definido por el cliente, y traducirlo al trabajo que hay que hacer durante
el proyecto y entregas concretas que en conjunto formen el producto requerido.
Incluye técnicas como el desglose del producto, el análisis de sus componentes, el
análisis de los requisitos, la ingeniería de sistemas, la ingeniería de valor (value enginee-
ring) y el análisis del valor (added value analysis).
SALIDAS (OUTPUTS):
Se obtiene el Enunciado del alcance del proyecto.
Enunciado del alcance del proyecto (Project Scope Statement)

Es el principal resultado de este proceso. Es la descripción del alcance del proyecto,
explicitando lo que está incluido y excluido, los principales entregables y el trabajo
necesario para completarlos, los criterios de aceptación que deben cumplir, los supuestos
–y el impacto de que no se cumplan–
Se centra en qué es lo que realmente se va a hacer en el proyecto y, además, en qué

va a ser revisado y aprobado por el cliente, partes interesadas y, en ocasiones, expertos
externos a la organización.
Es muy importante definir bien el alcance y tenerlo claro ya que será la base para la
planificación más detallada de los trabajos, guiará el trabajo del equipo durante su eje-
cución y será la base para evaluar si las propuestas de cambio o trabajos adicionales están
o no incluidos en el proyecto.
El Enunciado del alcance del proyecto será una entrada para otros procesos como
el de Crear la estructura de desglose del trabajo, EDT, o los encaminados a elaborar el
cronograma del proyecto –del área de conocimiento de gestión del tiempo–.
El project manager no deberá aceptar nuevos alcances que no estén en este docu-
mento por mucho que haya partes interesadas muy insistentes en incluir elementos de
su gusto. Por eso suele ser clave incluir una tabla de exclusiones e inclusiones dejando
claro qué está y qué no está incluido en el proyecto para evitar estas situaciones.
Este documento, junto con la EDT (WBS) y el Diccionario de la EDT (WBS

Dictionary) forman la línea de base inicial del alcance (scope baseline) que, a su vez,
forma parte del Plan de Dirección del Proyecto (Project Management Plan).
A veces se puede percibir un cierto grado de redundancia, entre el Acta de Cons-
titución y el Enunciado del Alcance de Proyecto. La principal diferencia es el nivel de
detalle contenido en cada uno de ellos, que mientras en el acta de constitución será de
alto nivel, en el caso del Enunciado del alcance, será detallado de forma progresiva.
En la siguiente tabla se pueden apreciar las diferencias principales:
Acta de Constitución del Proyecto Enunciado del Alcance del Proyecto
Propósito o justificación del proyecto Descripción del alcance del proyecto (elaborado
de manera progresiva)
Objetivos medibles del proyecto y criterios de Criterios de aceptación

éxito relacionados
Requisitos de alto nivel Entregables del proyecto
Descripción de alto nivel del proyecto Exclusiones del proyecto
Riesgos de alto nivel
Resumen del cronograma de hitos
Resumen del presupuesto
Lista de interesados
Requisitos para la aprobación del proyecto
Director del proyecto asignado, responsabilidad

y nivel de autoridad
Nombre y nivel de autoridad del patrocinador o

de quienes autorizan el acta de constitución del
proyecto
Este documento puede tener un contenido y organización como la de la siguiente tabla:
Enunciado del alcance del proyecto (Project scope statement)
Descripción del Es una breve descripción del alcance del producto que facilite la pla-
alcance del producto nificación de los trabajadores necesarios. El producto por su parte
(Product scope state- podrá ir definiéndose con más detalle conforme avance el proyecto.
Ej. Construir un prototipo de coche urbano con motor eléctrico y con
ment) una autonomía de 3 horas.
Exclusiones del pro- Indicar bien claro todo el trabajo que no está incluido y no se va a
yecto hacer.
(Project exclusions) Ej. El diseño de interiores no está recogido en la oferta arquitectónica.

Entregables del pro- Es todo lo que el proyecto creará incluidos el producto y los docu-
yecto mentos relativos al proyecto.
(Project deliverables) Ej. Maqueta escala 1:100 de la propuesta de urbanización.
Definen los procesos y criterios de aceptación del producto. Aunque
no se puedan indicar todos aquí se hará referencia a documentos adi-
Criterios de acepta- cionales.
ción del producto Ej. El tiempo de arranque del juego de ordenador debe ser inferior a
(Acceptance criteria) 2 segundos con una probabilidad de que el Pc se quede colgado del
0,001.
Tener la información así documentada y ordenada facilitará la labor de planificar el

trabajo a ejecutar de acuerdo a lo establecido. También facilitará su supervisión y control
a partir de una línea base del alcance (scope baseline) clara que indique los límites del
proyecto.
Actualizaciones a los documentos del proyecto (Project documents updates)

Al elaborar el Enunciado del alcance del proyecto, pueden surgir cambios, nuevas
ideas, nuevas partes interesadas, con nuevos requisitos. Por ello, como resultado de este
proceso, se podrán actualizar el registro de asunciones (assumptions log), la documen-
tación de requisitos (requierements documents), el registro de interesados (stakeholders
register), o la matriz de trazabilidad de requisitos (requirements traceability matrix).
3.3.5. Crear la estructura de desglose del trabajo (EDT)

Definido el alcance, se inicia el proceso de creación de la EDT, que es uno de los
más importantes del área de gestión del alcance del proyecto porque es donde realmente
se refleja todo el trabajo que va a haber que hacer (aunque está orientada a entregables,
debe incluir el alcance del producto, el alcance del proyecto y las propias tareas admi-
nistrativas y de gestión del proyecto).
Los resultados de los procesos de recopilar requisitos (collect requirements) y de
definir del alcance (define scope) formarán parte de las entradas (inputs) del proceso de
crear la EDT (Create WBS).
Mediante este proceso se subdividen el proyecto y sus entregables principales en
componentes más pequeños y manejables. El resultado es la EDT, una descomposición
jerárquica del alcance total del trabajo a realizar para cumplir con los objetivos del pro-
yecto y completar los entregables requeridos. La EDT ayuda a tener una visión estruc-
turada de los trabajos que hay que abordar. El trabajo total será la suma de los trabajos
que contienen y describen los componentes de menor nivel de la EDT, los paquetes de
trabajo, que deben permitir estimar su duración y coste, monitorizar su avance y verificar
el cumplimiento de sus criterios de aceptación.
La EDT debe incluir todo lo que cualquier persona del proyecto vaya a hacer. Lo
que no esté, no se hará.
La ubicación de este proceso dentro de su área de conocimiento y el grupo de

procesos es el siguiente:
Y el detalle del mismo se refleja en este esquema:

En ISO21500 existe también un proceso similar denominado «Crear la Estructura de

Desglose del Trabajo (Create work breakdown structure)» cuyo objetivo es facilitar una des-
composición jerárquica de los trabajos que deben ser completados para alcanzar los objetivos del
proyecto.
De acuerdo a ISO21500 la EDT facilita un marco para subdividir el trabajo del proyecto
en partes más pequeñas y manejables que pueden ser estructuradas siguiendo las fases de un
proyecto, los principales entregables u otro criterio que se considere válido y adecuado.
Entradas Salidas
Planes de proyecto Estructura de desglose del trabajo, EDT
Requisitos Diccionario de la EDT
Cambios aprobados
Observamos cómo no aparece como entrada el Enunciado del alcance del proyecto, salida del
proceso «Definir el Proyecto» cosa que sí sucede en PMBOK.
CREAR LA ESTRUCTURA DE DESGLOSE DEL TRABAJO, EDT

(CREATE WORK BREAKDOWN STRUCTURE, WBS)
Es el proceso que consiste en subdividir los entregables (deliverables) y el trabajo
del proyecto en componentes más pequeños y más fáciles de manejar: los paquetes
de trabajo (work packages).
El beneficio clave de este proceso es que proporciona un marco de trabajo de lo

que ha de ser desarrollado.
ENTRADAS (INPUTS):
Para elaborar la EDT se necesitará el Plan de Dirección de Proyectos, en particular

el plan de gestión del alcance –que especifica quien, cómo, con qué detalle,… elabora,
aprueba y actualiza la EDT-, y algunos documentos del proyecto como el enunciado
del alcance del proyecto –resultante del proceso anterior y que describe los trabajos
necesarios y lo que está excluido-, la documentación de requisitos –necesaria para saber
cuál es el resultado final esperado-, los procesos, plantillas de EDT de la organización,
archivos de proyectos anteriores y lecciones aprendidas.
Plan de Dirección de Proyecto (Project management plan)

Plan de Gestión del Alcance (scope management plan)

Este documento especifica, entre otras cosas, quien, cómo, con qué detalle… se
elabora, aprueba y actualiza la EDT.

Describe en detalle los entregables (deliverables) del proyecto, cuál es el trabajo
incluido y excluido proporciona un entendimiento común del alcance del producto
(product scope) entre todos los interesados.
Documentación de requisitos (Requirements documents)

Características y requerimientos detallados que el producto o servicio deben cumplir
para satisfacer las necesidades y expectativas del cliente, definidas en el proceso de
Recopilar requisitos.

Se considerarán como factores ambientales de la empresa las EDT´s que posea la
organización, EDT´s estándar de la industria o de los clientes, por ejemplo.
Activos de los procesos de organización (Organization process assets)

Se utilizarán los procedimientos, instrucciones y plantillas establecidas por la orga-
nización como mejores prácticas para elaborar la EDT, ficheros de proyectos anteriores
y lecciones aprendidas de proyectos anteriores.
Con la información anterior, el project manager y su equipo proceden a descom-

poner el alcance del proyecto y sus entregables en partes más pequeñas y manejables.
Para ello, identifican y analizan los entregables principales, estructuran y organizan la
EDT –por fases del proyecto, por partes del proyecto...–, descomponen los niveles
superiores de la EDT en componentes de menor nivel más detallados y pequeños, asig-
nan códigos a cada paquete de trabajo y verifican que la suma de los trabajos contenidos
en los paquetes de trabajo de menor nivel es igual al alcance total del proyecto.
Juicios de expertos (Experts judgement)

Como en otros casos, un experto en el sector o tecnología en la que se desarrolla el
proyecto puede ser de gran ayuda. Estos expertos podrán proceder de otras unidades de
la organización, consultores externos, partes interesadas, asociaciones técnicas y profe-

sionales, a fin de que nos ayuden en base al conocimiento o formación que disponen
con proyectos similares.
Se utilizará el juicio de expertos para analizar la información de partida necesaria
para elaborar la EDT, para establecer criterios de descomposición, definir el nivel de
destalle final de los paquetes de trabajo…
Descomposición (Decomposition)
Crear la EDT tiene que ver con identificar los entregables principales e ir dividién-
dolos hasta llegar a los paquetes de trabajo, lo que se denomina descomposición, que es
la principal herramienta para elaborar la EDT. De esta manera, cada entregable se divide
en paquetes de trabajo más manejables, de menor duración pero que sean verificables.
El número de niveles de descomposición será tal que permita una buena planifica-
ción, gestión y control del trabajo sin llegar a ser tan detallada que aumente innecesa-
riamente las tareas administrativas y no productivas de gestión. En concreto el paquete

de trabajo del último nivel debe ser tal que:
• pueda ser estimado (su coste y tiempo) de forma rápida y precisa,
• no sean trabajos de larga duración,
• que se pueden realizar sin interrupción ya que toda la información esté dispo-
nible,
• que pueda asignarse a una persona o grupo de personas específica (o subcon-
tratarlo completo).
Los pasos a dar son:
1. Obtener las entradas para elaborar la EDT:
a) La documentación de requisitos y su matriz de trazabilidad.
b) El Enunciado del alcance del proyecto.
c) Plantillas y procesos de la organización.
2. Definir el equipo que elaborará la EDT:
a) El responsable de proyecto y el equipo de dirección de proyecto.
b) El responsable de proyecto y personas asignadas al proyecto.
3. Analizar los trabajos necesarios para cumplir con objetivos del proyecto.
4. Selección, si procede, de la Plantilla de la EDT de un Proyecto similar.
5. Decidir cómo se va a estructurar y organizar el trabajo (subproyectos, fases, áreas
funcionales).
6. Determinar el tipo de presentación (estructura árbol, tabla, índice...).
7. Aplicar la técnica de descomposición hasta el nivel que permita una adecuada
gestión. Para ello, el responsable del proyecto y el equipo de proyecto deben
preguntarse si:
a) Dado el nivel de descomposición se puede asignar el trabajo a una persona.
b) Será capaz el equipo de estimar adecuadamente su coste y duración.
c) Será capaz el equipo de identificar las actividades necesarias para ejecutarlo.

d) Será el responsable de proyecto capaz de monitorizar y controlar su avance.
e) Se puede ejecutar en máx. 2 semanas, tiempo entre 2 reuniones de segui-
miento.
8. Aplicar la regla del 100% para verificar si todo el trabajo y solo el trabajo nece-
sario está incluido en la EDT (y que no hay trabajos redundantes).
9. Asignar el Código a cada componente de la EDT.
10. Definir el nivel de Cuentas de Control en el que se consoliden los resultados de
gestión.
11. Obtener inputs de otras partes interesadas relevantes.
12. Crear y cumplimentar los 7 primeros apartados del Diccionario de la EDT.
13. Obtener la aprobación interna de la EDT.
En ocasiones, se denomina «hammocks» a las tareas que se dejan a un nivel muy
general por ser demasiado pronto o no disponer de suficiente información sobre ellas.
Son aquellas en las que aplicamos la técnica de Planificación gradual (Rolling Wave
Planning)
Para obtener una buena EDT se debe:
• Realizar con la colaboración del equipo de proyecto (no debe hacerla el project
manager por su cuenta).
• Completar el nivel superior –que contendrá todo el alcance del proyecto– antes
de pasar al siguiente.
• Cada nivel inferior constará de paquetes de trabajo más pequeños.
• Incluir todo el trabajo que hay que hacer y no incluir nada que no sea realmente
necesario.
No obstante, no hay una única forma de elaborar una EDT. Como se ha mencio-
nado, casi todos los métodos más populares, suelen tener un enfoque de Arriba-abajo
(top-down approach), aunque en ocasiones se puede realizar un enfoque abajo a arriba
(bottom-up) para agrupar subcomponentes.
SALIDAS (OUTPUTS):
El resultado será la línea de base del alcance que incluye el Enunciado del Alcance
–del proceso anterior–, la EDT y el diccionario de la EDT, compuesto éste por fichas
para cada paquete de trabajo en las que se recoge: el código, la descripción del trabajo,
los supuestos y restricciones a la hora de ejecutar ese paquete de trabajo, la persona o
departamento responsable, la lista de hitos del cronograma asociados a ese paquete, las
actividades o paquetes relacionados, los recursos requeridos, las estimaciones de coste,
los requisitos de calidad y criterios de aceptación del paquete de trabajo, las referencias
técnicas y las referencias al contrato.
La línea de base del alcance, resultado de este proceso, se utilizará como entrada para
los procesos de controlar y validar el alcance, estimar costes y elaborar el presupuesto –
área de conocimiento de gestión de costes– e identificar riesgos y evaluarlos cualitati-
vamente –área de gestión de riesgos–.
La línea de base del alcance (scope baseline)

La línea base del alcance, es la versión aprobada del estado del alcance, la EDT y su
diccionario, que sólo debería ser modificada mediante procedimientos de control de
cambio
Conforme avance el proyecto, el project manager necesitará comparar el avance real
y su alcance con el inicialmente establecido. Por otra parte, cuando haya que añadir
nuevas funcionalidades que den lugar a nuevos entregables y paquetes de trabajo, el
project manager debe cambiar la línea de base para incluir esos nuevos trabajos, guar-
dando a lo largo del proyecto las diferentes líneas de base incluida la inicial.
Resumiendo, la línea de base del alcance está compuesta por los siguientes elemen-
tos:
El Enunciado del Alcance del proyecto (Project scope statement): incluye la

descripción del alcance, entregables principales, asunciones y restricciones.
• EDT (WBS): Descomposición jerárquica del trabajo de proyecto para ser llevada
• a cabo por el equipo
• Paquetes de trabajo (Work Package): El nivel más bajo de la EDT, con un
identificador único. Cada paquete de trabajo forma parte de una cuenta de
control. . Una cuenta de control, es un punto de control de gestión, donde el
alcance, presupuesto y plazo son integrados y comparados para su medición y
control, por ejemplo, mediante método de valor ganado.
• Paquetes de planificación (Planning package): Es una estructura de desglose de
trabajo por debajo de las cuentas de control, y por encima de los paquetes de
trabajo, que incluye contenido de trabajo, pero sin actividades
• Diccionario de la EDT (WBS Dictionary): Documento que proporciona detalle
sobre los elementos que forman la EDT
Estos elementos los vemos en detalle a continuación.
La línea base será el elemento con el que se comparará el avance del proyecto y su
grado de cumplimiento en las fases de seguimiento y control y permitirá decidir si la
actividad concreta está acabada. Esta línea base del alcance (scope baseline) formará parte
del Plan de Dirección del Proyecto.
La Línea de Base del Alcance será entrada para múltiples procesos, por ejemplo:
• Validar el Alcance.
• Elaborar el plan de Dirección del Proyecto.
• Definir las actividades.
• Estimar los costes.
• Determinar el presupuesto.
• Identificar riesgos.
• Realizar el Análisis Cualitativo de Riesgos.
Estructura de desglose de Trabajo, EDT (Work Breakdown Structure, WBS).

Una EDT no es una lista de tareas. Una EDT es mucho más que una lista de tareas.
Son varias las diferencias entre ellas:
• La EDT incluye –y está definida y orientada a– entregables.
• Una lista no permite hacer un desglose de cada actividad en tareas más pequeñas
y manejables.
• Una lista no da una imagen general del trabajo total, ni de cómo un paquete de
trabajo se relaciona con el total.
La EDT obliga al equipo a pensar sobre el proyecto, a revisar relaciones, partes que
faltan y el producto final es mucho más completo y útil y es mejor comprendido, asu-
mido por el equipo participante y más realista.
Frente a un diagrama de red –que se tratará en la planificación del tiempo– no

muestra precedencias entre tareas ya que no indica qué tarea se hace antes que otra –si
es necesario acabar una para empezar otra–.
A cada paquete de trabajo (work package) se le asocia un código de identificación
que indique el paquete de trabajo, el nivel de la EDT en el que está y facilite su búsqueda
en el diccionario de la EDT.
La estructura de la EDT se puede hacer:
• Utilizando las fases del ciclo de vida del proyecto como primer nivel de des-
composición y los entregables en segundo nivel.
• O usando los entregables como primer nivel o utilizando subproyectos que
pueden ser ejecutados por proveedores.
Ejemplos serían los tres siguientes –la ejecución de un chalet, una planta depuradora
y el desarrollo de un software–, si bien en cada caso y debido a la diferente complejidad
del proyecto, cabría hacer desgloses más detallados:
En la elaboración de la EDT, como en la recopilación de requisitos, se puede abordar

una elaboración gradual (Progressive elaboration), más detallada en los paquetes de tra-
bajo más definidos y menos detallada en los que están por venir.
Algunos aspectos muy importantes a no olvidar en relación a la EDT (WBS):
• Los entregables (deliverables) o actividades (activities) que aparece en la EDT
aprobada son los realmente necesarios y los que se abordarán en el proyecto.
Los que no aparecen, no forman parte del proyecto.
• Los paquetes de trabajo, elemento de inferior nivel deben incluir entregables:
– cuyo trabajo y duración se puede estimar de forma realista y confiable,
– se pueden completar en un plazo corto, que puede ser el espacio entre dos
reuniones semanales de seguimiento del equipo,
– del que se dispone de toda la información por lo que se puede ejecutar sin
interrupción,
– e, incluso, puede subcontratarse al estar perfectamente acotado y definido.
• Deben estar codificados para que el código identifique unívocamente cada
componente e identifique el nivel de descomposición al que se puede encontrar
el componente.
Entre los muchos beneficios de la EDT se destacan que:
• Evita dejarse tareas importantes.
• Da una idea general de dónde está cada pieza dentro del cuadro general y esto
da a su responsable una mayor capacidad de realizarlo mejor.
• El equipo se centra en lo que realmente hay que hacer.
• Es la base para estimar costes, duraciones, riesgos, recursos necesarios…
• Si ha participado el equipo éste lo hace suyo y su motivación aumenta.
• Facilita la comunicación y cooperación con los interesados.
Es, en definitiva, la base del proyecto a la que referirse prácticamente en todos los
procesos que se describan en los próximos capítulos. Un project manager profesional

no puede comenzar un proyecto sin tener una EDT (WBS) elaborada con su equipo,
con entradas de las partes interesadas y que cumpla con los requerimientos del producto
y el proyecto.
Por último, durante la fase de ejecución el EDT se utilizará:
• para valorar cambios en el alcance propuestos o necesarios,
• para identificar el impacto que los cambios propuestos tengan sobre el proyecto,
• como una herramienta de comunicación, y
• como una ayuda para que cada miembro del equipo comprenda sus tareas, sus
funciones y su interrelación con la de otros.
Diccionario de la EDT (WBS Dictionary)

Como se ha podido observar en los ejemplos, la EDT da descripciones cortas de
una o dos palabras de las actividades a realizar pero no deja claro cuál es el trabajo
realmente incluido en ella. Por ello se debe definir, como complemento a la EDT, un
Diccionario de la EDT.
Éste contendrá una descripción del trabajo que asegure que el responsable de eje-
cutarlo sepa lo que tiene que hacer, los pasos que debe dar y su alcance concreto, las
relaciones con otras tareas, la fecha de inicio, los hitos… Por todo ello este diccionario
puede utilizarse como parte del sistema de autorización del inicio de los trabajos.
Las entradas de un diccionario de la EDT pueden tener un esquema similar al que
se presenta en la tabla siguiente:
Testado del prototipo por parte del cliente
Fecha de actualización 12/07/2010
Identificador y nombre 3.1 Prueba del prototipo por cliente
El objeto de esta prueba es que el cliente vea una prueba beta del
Descripción del Trabajo modelo que le permita probarlo y ver si las funcionalidades implan-
tadas son correctas, son excesivas o conviene complementarlas.
Responsable Equipo de prototipado con el cliente
Entregables (delivera- Informe preliminar

Informe definitivo
bles) Maqueta
4-abril: entrega al cliente y formación por equipo
10-abril: visita al cliente y entrevista para anotar opiniones, suge-
Hitos (milestones) rencias, problemas…
20-abril: ajuste y aprobación final por el cliente
Requerimientos de cali- El prototipo debe cumplir los requerimientos establecidos por el
dad y aceptación cliente y recogidos en el documento de requisitos.
Duración 7 meses
Fecha de entrega 12/02/2011
Código de proyecto RRTT-2010
Recursos necesarios Formación al equipo (técnico junior): 1.000 euros

ycoste estimado Entrevista con cliente (técnico sénior y junior): 3.000 euros
Ajuste final y aprobación (2 técnicos junior): 2.000 euros
Interdependencias con
No
otros proyectos
Aprobado por Project manager
Plan (preliminar) de recursos humanos y adquisiciones 193

Los cambios que hemos detectado y que hemos recogido en el alcance del producto
actualizado afectarán a otros documentos como el cronograma, el presupuesto…, que
deberán ser actualizados para mantener un Plan de Gestión del Proyecto coherente.
Si durante el proceso de crear la EDT se produce una petición de cambio que es
aprobada será necesario actualizar el Enunciado del alcance del proyecto (project scope
statement), la EDT (WBS) y su Diccionario (WBS Dictionary).
Otros documentos que puede ser necesario actualizar:
Registro de asunciones: Que se actualizará con las restricciones y asunciones que
sean identificadas.
3.4. PLAN (PRELIMINAR) DE RECURSOS HUMANOS Y ADQUISICIONES
3.4.1. Plan (preliminar) de recursos humanos

Comentamos al hablar de los grupos de procesos de inicio que ISO21500 propone
un tercer proceso llamado «Establecer el equipo de proyecto». PMBOK no lo tiene
expresamente pero parece lógico pensar que, para proceder a elaborar el Plan de Direc-
ción, sea necesario que el project manager presente el proyecto a los departamentos
implicados y que éstos asignen personas que ayuden al project manager a planificar el
proyecto.
También es cierto que, aunque no aparezcan como tal en PMBOK, el project
manager debe tener una primera idea de qué recursos va a disponer y qué elementos de
la EDT va a subcontratar para poder hacer estimaciones de costes y plazos.
Por tanto, aunque el proceso «Planificar la Gestión de Recursos Humanos» se cerrará
una vez completado el proceso de «Estimar los recursos de cada actividad» correspon-
diente al área de conocimiento de gestión de recursos, es bien cierto que, una vez
definida la línea de base del alcance, se puede proceder a identificar y documentar:
• los trabajos que se realizarán internamente,

• los trabajos que, en principio, se externalizarán.
De esta forma se podrán también definir de forma preliminar los roles y responsa-
bilidades del proyecto, las habilidades requeridas, las relaciones y flujos de reporte.
Para hacer un primer Plan de Recursos se tendrá en cuenta el Plan de Dirección
del Proyecto –que define cómo se va a ejecutar el trabajo necesario para lograr los
objetivos del proyecto…–, la línea de base del alcance, los factores ambientales de la
organización –cultura y estructura, recursos humanos disponibles, políticas de recursos
humanos vigentes…– y los activos de los procesos de la organización –descripciones de
roles existentes, plantillas de organigramas y matrices de asignación de responsabilidades,
información histórica y lecciones aprendidas sobre gestión de recursos humanos en
proyectos anteriores…–.
Mediante el uso de herramientas como el organigrama y matrices de asignación de
responsabilidades de la organización o descripciones de perfiles, autoridades, compe-
tencias y responsabilidades, se elaborará un organigrama de proyecto, una definición de
perfiles necesarios y, dependiendo de la complejidad del proyecto, una matriz de asig-

nación de responsabilidades preliminar.
3.4.2. Adquirir el equipo (preliminar) de proyecto

Teniendo en cuenta el Plan de Dirección de Proyecto, la línea de base del alcance
y el plan (provisional) de recursos humanos se realizarán:
• asignaciones provisionales de personal al proyecto –que se pueden reflejar en
los organigramas, matrices de asignación de responsabilidades...–,
• y un calendario de recursos –períodos de tiempo en los que deberán trabajar los
recursos en el proyecto–,
Que serán entradas para los procesos de estimar la duración de las actividades y
elaborar el cronograma –área de gestión del tiempo– y definir los recursos necesarios
para cada actividad y elaborar el presupuesto –del área de gestión de costes–.
Teniendo en cuenta este equipo preliminar se puede continuar y completar la pla-
nificación.
3.4.3. Plan (preliminar) de gestión de las adquisiciones

Las decisiones de adquisición pueden realizarse:
• Directamente una vez definido el alcance del proyecto y el trabajo desglosado
en la correspondiente EDT.
• Tras el proceso de planificación en el que se hayan analizado los recursos dis-
ponibles, se haya realizado el análisis de riesgos asociado a la ejecución de los
diferentes componentes de la EDT...
Este planteamiento es compatible con el hecho de que de acuerdo a la guía de
PMBOK:
• Los documentos de compras –salidas del proceso de «Planificar la gestión de

compras»–, sean una entrada para el proceso de identificación de riesgos.
• O los acuerdos o contratos –salidas del proceso «Efectuar las compras»– sean
entradas para el proceso de «Determinar el Presupuesto».
Es por ello, que a efectos de este manual, se considere que, como por otra parte
muestra la experiencia:
• Se puede realizar una primera valoración de aquellos paquetes de trabajo que se
van a externalizar, realizando para ello un análisis «hacer o comprar», contac-
tando si procede con proveedores a los que se les haya enviado una primera
versión de los documentos de proyecto.
• Se pueda cerrar la planificación de la gestión de adquisiciones una vez cerrado
el proceso de identificación de riesgos y previamente al cierre del Plan de
Dirección de Proyecto.
Planificar la calidad de un proyecto 195
3.5. PLANIFICAR LA CALIDAD DE UN PROYECTO
Tras definir el alcance del proyecto, el project manager, en colaboración con el

responsable de calidad, puede abordar ya el proceso de elaboración del Plan de Calidad
que, a su vez, generará nuevas actividades que habrá que incorporar en la estructura de
desglose de tareas (y que, a su vez, habrá que incorporar en el cronograma y en el
presupuesto que se cierren posteriormente).
De esta manera las actividades de calidad del proyecto estarán en el alcance, estarán
en el cronograma y estarán en el presupuesto.
Nuevamente en este caso, nos encontramos con el carácter iterativo de la planifi-
cación de un proyecto porque, a su vez, el resultado de la planificación del tiempo –el
cronograma– y de la planificación de costes –el presupuesto– serán datos que permitirán
programar las actividades de calidad y establecer unos presupuestos máximos para estas
actividades –y cerrar con todo ello el Plan de Calidad–.
3.5.1. Conceptos asociados a la calidad

No atender adecuadamente la calidad en un proyecto conlleva defectos, reparacio-
nes, entregables rechazados, pérdida de confianza del cliente y, en definitiva, más riesgos,
más coste y más tiempo. Por ello, la calidad preventiva es un elemento vital en la gestión
de un proyecto.
El project manager deberá saber qué considera como calidad aceptable el cliente,
traducirla a indicadores medibles, concretar cómo va a medirla durante el desarrollo del
proyecto y tener claro, poner por escrito y comunicar a las partes interesadas, qué pre-
tende hacer para garantizar que se cumplen los requerimientos del cliente.
La gestión de la calidad del proyecto incluye según la A Guide to the Project Mana-
gement Body of Knowledge (PMBOK® Guide) los procesos y actividades que el project
manager y su organización han decidido:
• Para dejar claras las responsabilidades, objetivos, indicadores y políticas de cali-

dad.
• Para asegurar que el proyecto y el producto entregado al cliente cumplan con
las necesidades y requerimientos inicialmente establecidos.
Estas actividades tienen también por objetivo lograr un proceso de identificación
de mejoras que aplicar en el propio proyecto y proyectos siguientes, generando así un
procedimiento y una cultura de mejora continua.
Comprende tres procesos:
• Planificar la calidad (Plan quality management).
• Gestionar la calidad (Perform quality assurance).
• Controlar la calidad (Control quality).
Es importante resaltar que este proceso trata tanto de la calidad del producto como
del proyecto y que, si los enfoques de gestión de la calidad del proyecto (Project quality
management) son comunes a todos, las medidas y técnicas relativas a la calidad del pro-
ducto serán diferentes para cada tipo de producto
Algunos referentes históricos de la calidad

La calidad ha sido una preocupación creciente en los últimos 60 años desde que
Toyoda implantó sus sistemas de producción en Toyota.
Algunas de las personalidades del mundo anglosajón más relevantes en esta área son
Crosby, quien basándose, como todos los siguientes autores, en los modelos de pro-
ducción de la marca de automóviles Toyota, definió la necesidad del Error Cero, esto
es, lograr hacer las cosas bien a la primera.
Por su parte, Juran definió la calidad de forma que permitiera establecer indicadores
de éxito mediante preguntas relativas a:
• si el producto o servicio había cumplido con las expectativas de las partes intere-
sadas,
• si satisfacía una necesidad real, o
• si era fiable y seguro el producto entregado al cliente.
Por su parte, Deming subrayó y dedicó sus esfuerzos a tratar de explicar que la calidad
se encuentra en el sistema de gestión del proyecto y del producto pero, sobre todo, de
la empresa en general. Según este autor, un 85% del coste de la no calidad (Cost of No
Quality) estaba asociado a problemas de gestión; no a las personas sino a los sistemas,
políticas y procedimientos de calidad de la empresa. De lo que se deducía que era res-
ponsabilidad de la alta dirección explicar, formar y monitorizar el trabajo de los emplea-
dos para lograr así una mejor calidad y una mejora continua, y poner a su disposición
los medios para implantarla en cada proyecto.
Por último, citamos a Deming quien propuso el ciclo de Planificar, Ejecutar, Moni-
torizar y Actuar (Plan, Do. Check, Act = Ciclo PDCA), basado en los utilizados por
los ingenieros de Toyota (sistema Kaizen) y sus sistemas de mejora continua. En ambos
casos, todos los niveles de personal afectado se implican y responsabilizan de la calidad
de su trabajo y de buscar nuevas mejoras, ya incrementales, ya de nuevos diseños o
conceptos.
En la actualidad nuevos conceptos en búsqueda de la Gestión de la Calidad Total

van tomando mayor o menor protagonismo: TQM, Seis Sigma…
Calidad y otros conceptos relacionados

Calidad:
La calidad se define desde la perspectiva del cliente como el grado en que el proyecto
cumple los requerimientos establecidos.
Esta definición ya deja clara la necesidad de conocer los requerimientos implícitos
y explícitos del producto y el proyecto. Identificarlos todos lleva tiempo y esfuerzo,
pero encontrarse con un requerimiento inatendido en fases avanzadas del proyecto es
mucho más grave y el tiempo, esfuerzo y coste para corregir la situación será muy
superior.
Calidad (Quality) y Grado (Grade):

La calidad se refiere a unas características del producto que cumplen los requisitos
del cliente. El grado se refiere a una categoría que asigna a productos y servicios con
igual uso funcional, un nivel de características técnicas y un valor económico diferente.
Juran distinguía entre calidad –si el producto satisface los requerimientos del cliente–
y grado –si el producto es complejo, de alto valor…–. Si pedimos una hamburguesa y
cumple nuestras expectativas será un producto de calidad –hemos obtenido lo que
deseábamos, sin sorpresas desagradables–. Si pedimos una langosta a un precio alto que
resulta no ser fresca y no cumple nuestras expectativas habremos obtenido un producto
de alto grado pero baja calidad. La langosta es un producto de mayor grado, porque, en
general, la gente lo valora más y está dispuesta a pagar más por él aun cumpliendo la
misma función: alimentar al cliente.
Precisión y exactitud:
La precisión indica el grado de dispersión en los valores de un parámetro obtenidos
al medir diferentes unidades de un producto. Por su parte, la exactitud indica el grado
de cercanía de lo medido con la realidad. De esta manera unas mediciones muy precisas
pueden ser inexactas y viceversa.
En la figura siguiente, teniendo en cuenta que el valor objetivo es el centro de la
diana, la figura izquierda muestra unos resultados poco precisos (hay dispersión), pero
más exactos (se sitúan en torno al punto o valor objetivo) que los de la figura de la
derecha, donde ocurre lo contrario: las mediciones son precisas (no hay dispersión) pero
muy inexactas (alejadas del valor objetivo).
Otros aspectos clave de la calidad:

Debemos distinguir entre
• Prevención (evitar que haya errores) e inspección (identificar esos errores si
ocurren)
• Muestreo por atributos (el resultado es conforme o n) y muestreo aleatorio (los

resultados se ordenan en una escala continua)
• Tolerancias (rangos de valores aceptables) y límites de especificación (límites de
variación en un proceso estadísticamente estable)
Hay 5 niveles de gestión efectiva de la calidad:
1. Que el cliente encuentre los defectos
2. Detectar y corregir los defectos antes de que lleguen al cliente
3. Utilizar el aseguramiento de calidad para controlar los procesos y no los defectos
4. Incorporar la calidad dentro de los procesos de planificación
5. Crear una cultura de calidad en la organización
Prevención antes que inspección:
Se debe planificar, diseñar e integrar la calidad en el proceso, no esperar al final para
ver qué elementos tienen errores y cuáles no.
La calidad tiene mucho más que ver con la prevención que con la inspección, con
establecer mecanismos que nos garanticen que nuestros resultados van a ser homogé-
neos, predecibles y satisfactorios para el cliente, que con tener un grupo de inspectores
que identifican productos defectuosos y los rechazan para su ajuste o corrección. Tiene,
en definitiva, más que ver con ser capaces de evitar que ocurra un error que con ser
capaces de detectarlo.
Los programadores de un software estarán aplicando prevención si elaboran tests para
cada unidad antes de comenzar a escribir códigos para así identificar los aspectos que
pueden ir mal y corregirlos a tiempo.
Si, por el contrario, en una cadena de producción en la que los elementos previos
a su moldeado deben salir a una temperatura de 400 grados y hay un empleado que
mide la temperatura para apartar aquellos que no lo cumplan, el empleado está inspec-
cionando.
Tendencias y prácticas emergentes en gestión de calidad

Importancia de la satisfacción del cliente:
Se refiere a la importancia de identificar, comprender y satisfacer los criterios de
éxito del producto que espera el cliente.
La satisfacción del cliente es un elemento clave de la filosofía de la Gestión Moderna
de la Calidad que busca comprender, evaluar, definir y gestionar las expectativas del
cliente para que el producto consiga satisfacer los requisitos del cliente, que se pueden
definir y que lo componen dos aspectos:
• Conformidad con los requerimientos: el proyecto debe producir lo que se
acordó que produciría. En este sentido, el director del proyecto debe evitar
realizar trabajos adicionales y ofrecer funcionalidades extras (gold plating) si no
han sido solicitados formalmente y por escrito por el cliente. Además, el project
manager realizará la correspondiente evaluación del cambio de acuerdo al pro-
cedimiento establecido. La calidad, como se ha definido inicialmente, es cumplir
con los requerimientos establecidos por el cliente. Los trabajos adicionales
supondrán un coste adicional, abordando funcionalidades no incluidas en el

proyecto, y no serán abonados por el cliente –salvo que hayan sido solicitadas
por él–.
• Adecuación al uso: el producto o servicio debe satisfacer las necesidades del
cliente.
Mejora continua:
Es un procedimiento integrado en la dirección del proyecto que permite producir
mejoras incrementales, tanto en los procesos del proyecto como en los requisitos del
producto.
Responsabilidad de la dirección:
Concepto resaltado por Deming: la dirección de la empresa es la responsable final
ya que debe crear una cultura y política enfocada a la calidad, y que ponga a disposición
del equipo los recursos necesarios para garantizar la calidad.
Acuerdos mutuamente beneficiosos con socios y proveedores:
Los socios y proveedores deben estar igualmente implicados en la calidad de nuestro
proyecto, por ello debemos lograr transmitirle nuestra cultura y llegar a acuerdos bene-
ficiosos para ambas partes que garanticen el éxito de la calidad en nuestros productos
Consideraciones para adaptar la gestión a nuestros proyectos

La gestión de la calidad en el proyecto se deberá adaptar a aspectos como:
• La política de calidad y auditoría de la organización (procesos y procedimientos
de calidad establecidos)
• Estándares de cumplimiento y estándares legales (en la industria, en la legislación,
…)
• La mejora continua dentro de la organización
• La implicación de los interesados (y su grado de colaboración)
La calidad en entornos ágiles y adaptativos

La gestión de la calidad en el estos entornos se produce de manera mucho más
continua y periódica, en vez de concentrarse hacia al final del proyecto.
Las reuniones de retrospectiva buscan identificar mejoras y oportunidades para apli-
carlas en las siguientes iteraciones
Para ello, los entornos ágiles se concentran en pequeños paquetes de trabajo en los
que se trata de que las funcionalidades se vayan incorporando y validando de forma
continua.
Responsabilidades del project manager

El project manager gestiona la calidad obteniendo los objetivos de calidad del cliente
y traduciéndolos a unos indicadores que al medirlos le informen si se están cumpliendo.
Por ello, es tan importante saber qué es lo que las partes interesadas y, sobre todo, el
cliente o el usuario final entienden por calidad, cuáles son los niveles que ellos van a
considerar aceptables, cuándo van a considerar que el producto y proyecto han sido un
éxito.
El project manager es el responsable final del cumplimiento de los estándares de
calidad del proyecto y el cumplimiento fiel de los requerimientos del cliente, aunque
se pueda apoyar en su equipo de trabajo o haya un departamento de calidad que realice
el control de calidad (medidas, informes y recomendaciones).
Es responsabilidad del project manager conocer:
• Los estándares –ISO, PMBOK® Guide, estándares internos de la organiza-
ción…, que sin ser legalmente obligatorios recogen buenas prácticas en el desa-
rrollo de proyecto–.
• La legislación vigente –de obligado cumplimiento, en diferentes áreas como
seguridad laboral, medio ambiente, protección de datos, legislación laboral…–
• Otras reglas o guías metodológicas que puedan ser de interés.
Para juzgar la calidad de un servicio o producto el project manager debe saber:
• para qué sirve,
• en qué se va a utilizar ese producto,
• qué se supone que tiene que hacer y, más importante,
• según qué criterios se va a juzgar el éxito del producto o servicio.
Una vez que tiene la respuesta clara y concreta a estas preguntas puede empezar a
diseñar tests que vayan asegurando que el producto cumple con los requerimientos. El
producto será de calidad si cumple los requisitos establecidos por el cliente, no porque
sea mejor o peor que otro que haya en el mercado.
3.5.2. La gestión de la calidad en un proyecto

Gestionar la calidad será por tanto, crear y cumplir políticas y procedimientos que
garanticen que se cumplen los requerimientos establecidos. Este esfuerzo de gestión se
reflejará en:
• El Plan de Gestión de la Calidad (quality management plan), que describirá
cómo deberá implantar el equipo de proyecto la política de calidad en cada
proyecto concreto.
En este proceso de gestión preventiva el project manager tiene un papel fun-
damental, si bien buena parte del control de la calidad pueda realizarse desde el
departamento de calidad, si existe:
• Recomendando mejoras en las políticas y procesos de la organización.
• Considerando la calidad siempre que se solicite o recomiende un cambio
en cualquiera de las tres principales restricciones del proyecto (alcance,
coste y tiempo).
• Asegurándose que el responsable de cada paquete de trabajo lo ha revisado
él mismo antes de enviarlo al cliente –ya que, aunque el project manager
no haga el trabajo real, es responsable final de la calidad de los entregables

y del proyecto completo–.
• Dedicando tiempo a buscar posibilidades de mejora en los procesos y for-
mas de trabajar de forma sistemática mediante el Plan de Mejora Contínua.
• Garantizando que las metodologías y procesos se siguen tal y como han
sido aprobados.
En el esquema siguiente se pueden ver los tres procesos que incluye esta área de
conocimiento, repartidos entre los grupos de procesos de planificación, ejecución y
supervisión y control:
Como vimos en el primer capítulo existen algunas diferencias menores –de denominación
únicamente– entre los procesos de la Guía del PMBOK y la ISO21500 en lo que a gestión
de la calidad se refiere. En el siguiente cuadro se reflejan los procesos de PMBOK y los de
ISO21500 (estos últimos en cursiva).

Planificar la gestión Gestionar la calidad Controlar la calidad
de la calidad (Realizar el asegura- (Realizar el control de
(Planificar la calidad) miento de la calidad) la calidad)
Estos procesos tienen los siguientes objetivos:
Identificar los estándares de calidad y requerimientos del proyecto y

Planificar la Gestión del producto, la definición de los trabajos necesarios para cumplir con
de la Calidad los estándares, qué mediciones se van a realizar y cómo para asegurar
(Plan quality manage- que se cumplen los requerimientos, equilibrar las demandas de calidad
ment) con las de coste, tiempo, riesgos… para con todo ello, crear un Plan
de Gestión de la Calidad que forme parte del Plan de Dirección del

Proyecto.
No existen diferencias significativas entre lo que establece PMBOK e

ISO21500 salvo que esta última lo denomina «Planificar la Calidad (Plan
Quality)».
Es el proceso de trasladar el plan de gestión de calidad en actividades
de calidad ejecutables, auditar los requisitos de calidad y los resultados
de los controles de calidad para garantizar los estándares de calidad
apropiados (tanto del producto como de los procesos). Utiliza las
Gestionar la calidad medidas procedentes del control de calidad para ver si se están traba-
jando de acuerdo a los procedimientos establecidos y que éstos son
(Manage Quality) eficientes o se requiere tomar medidas correctivas, preventivas o de
mejora en la forma de trabajar.

ISO21500.
Incluirá la realización de las mediciones planificadas, la identificación
de posibles mejoras, la validación de los entregables, la actualización
de documentos del proyecto, del Plan de Gestión de la Calidad, del
Controlar la calidad Plan de Dirección del Proyecto y la propuesta de cambios.
(Control quality)
ISO21500 salvo que esta última lo denomina «Realizar el Control de la
Calidad (Perform Quality Control)».
Puesto que estamos en el grupo de procesos de planificación, nos centraremos, de

momento, en el proceso de planificar la calidad.
3.5.3. Planificar la gestión de la calidad

Como se ha comentado al introducir la planificación de la calidad, una vez definido
el alcance del proyecto –y, muy especialmente, recogidos los requerimientos del pro-
ducto y del proyecto–, el project manager, en colaboración con el responsable de cali-

dad, puede abordar ya el proceso de elaboración del Plan de Calidad.
Es importante que las actividades de calidad definidas se incorporen a la estructura
de desglose de tareas para que, al elaborar el cronograma y el presupuesto, estén presu-
puestadas y programadas.
El proceso de planificar la gestión de la calidad de un proyecto tiene por objetivos:
• Identificar los requisitos de calidad y/o los estándares que deben cumplir el
proyecto y sus entregables
• Definir qué actividades se van a llevar a cabo para lograr cumplirlos.
• Documentar cómo va a demostrar el proyecto que cumple con estos requisitos
y estándares.
Un buen Plan de Gestión de la Calidad de un proyecto definirá cómo se va a ges-
tionar y validar la calidad a lo largo de la vida del proyecto para que proyecto y producto
cumplan los requisitos establecidos.
El siguiente esquema muestra dónde se sitúa el proceso de elaborar el Plan de Calidad

de un Proyecto, dentro del área de conocimiento de la Gestión de Calidad y dentro del
grupo de planificación:
En este proceso básicamente se:

• Buscan procesos y normas de calidad existentes para la gestión del proyecto y
sus productos.
• Crean procesos y normas adicionales específicos del proyecto.
• Traducen a indicadores medibles los requerimientos del cliente, esto es, qué
entiende y cómo medirá el cliente que el producto o servicio entregado es de
calidad o cómo va a medir el éxito del proyecto.
• Determinan qué trabajos se debe realizar para cumplir las normas y seguir los
procesos definidos.
• Incorporan a la EDT las tareas definidas y se actualiza el cronograma y el pre-
supuesto.
• Identifican qué partes del proyecto y en qué momento se van a controlar.
• Definen los niveles de calidad que el proyecto debe alcanzar sobre los que se
medirá el desempeño del proyecto.
• Determinan cómo medirlos para garantizar que se cumplen las normas y que los
procesos son los adecuados para lograr productos que cumplan las especifica-
ciones definidas.
• Equilibran las restricciones de alcance, calidad, coste, tiempo, riesgos y satisfac-
ción del cliente.
Para ello, el project manager y su equipo deberán contar con el registro de intere-
sados, la línea de base del alcance, del coste, del cronograma así como la información
relativa a los activos de los procesos de la organización y condicionantes del entorno de
la empresa que puedan afectar al proceso de planificación, gestión y control de la calidad.
En el esquema siguiente se presenta de forma sencilla las entradas (inputs), técnicas
y herramientas (techniques and tools) y resultados (ouputs) de este proceso que se deta-
llan en el punto siguiente:
En ISO21500 existe un proceso muy similar denominado «Planificar la Calidad (Plan

Quality)» cuyo objetivo es determinar los requisitos de calidad y estándares que son aplicables
al proyecto o a sus entregables y definir cómo se lograrán cumplir teniendo en cuenta los objetivos
del proyecto.
Indica la ISO21500 que implica:
• Determinar y acordar con el cliente y partes interesadas los objetivos y estándares rele-
vantes a tener en cuenta.
• Establecer las herramientas, procedimientos, técnicas y recursos necesarios para cumplir
los estándares relevantes.
• Definir metodologías, técnicas y recursos para ejecutar las actividades de calidad defi-
nidas.
• Elaborar el Plan de Calidad que incluye las revisiones a realizar, los roles y respon-
sabilidades y su programación en el cronograma de proyecto.
• Consolidar toda la documentación relativa a la calidad en el Plan de Calidad.
Subraya la necesidad de que sea la propia organización la que tenga desarrollados políticas
y procedimientos de calidad que puedan ser aplicados y adaptados al proyecto concreto.
Entradas Salidas
Planes de proyecto Plan de Calidad
Requerimientos de calidad
PLANIFICAR LA GESTIÓN DE LA CALIDAD (PLAN QUALITY

MANAGEMENT)
Se definen las actividades a realizar durante el proceso de gestión de la calidad,
identificando requisitos de calidad, definiendo las medidas de control de calidad,
estableciendo los parámetros de aceptación y cómo proceder en caso de no confor-
midad con los requisitos establecidos.
ENTRADAS (INPUTS):
Entre la información necesaria para elaborar el Acta de Constitución, el Plan de

Dirección del Proyecto –muy especialmente la línea de base del alcance (donde se
recogen los requerimientos y sus criterios de aceptación) y la línea de base del crono-
grama –para programar las actividades de calidad–, los documentos de proyecto (con el
registro de partes interesadas –con sus necesidades y expectativas respecto al producto
y proyecto–, el registro de riesgos, la documentación de requisitos que debe cumplir el
proyecto y el producto para satisfacer las necesidades de las partes interesadas más rele-
vantes) y, por último, la legislación nacional y las normas y estándares del sector (factores
ambientales) y las normas establecidas dentro de la organización (Activos de los Procesos
de la Organización).
Acta de Constitución
Nos dará información de alto nivel sobre la descripción del producto, características
más relevantes. Contendrá los requisitos para la aprobación del proyecto, objetivos
medibles y otros objetivos de éxito que puedan estar relacionados con la calidad del
proyecto.
Plan de Dirección del Proyecto

En el Plan de Dirección del Proyecto están, entre otros:
• El plan de gestión de requisitos que indicará como identificar, revisar y gestionar
los requisitos en el proceso de calidad
• El plan de gestión de riesgos ya que habrá riesgos que conlleven unas medidas
de aseguramiento y control de calidad específicas para minimizar o evitar esos
riesgos.
• El plan de gestión de interesados que indicará cómo se deben recoger las nece-
sidades, expectativas y requisitos de los interesados que forman la base para el

plan de calidad.
• La línea de base del alcance –en el Enunciado del Alcance deben aparecer bien
definidos los criterios de aceptación del proyecto y el producto, y en la EDT y
su Diccionario deben haberse definido bien los criterios de aceptación de cada
uno de los paquetes de trabajo–.
Lo forman el Enunciado del alcance del proyecto –descripción del proyecto,
entregables (deliverables) y criterios de aceptación (acceptance criteria)–, la EDT
–todo el trabajo que hay que realizar y sólo el que hay que realizar– y su dic-
cionario que describe con más detalle el contenido y condiciones del trabajo.
Esta línea de base contendrá aspectos muy relevantes a la hora de planificar la
calidad como los umbrales de aceptabilidad de cada entregable para considerar
que cada uno cumple con la calidad establecida. Estos umbrales tendrán un
impacto sobre el coste y el cronograma del proyecto.
En este sentido el project manager deberá dedicar un trabajo importante a iden-

tificar los estándares de calidad oficiales, los propios de la empresa, los estable-
cidos por el cliente y aquellos que él, por propio interés, defina.
• La línea de base del cronograma –para programar las actividades identificadas de
aseguramiento y control de calidad–. Para iniciar el Plan de Gestión de Calidad
y definir las actividades de calidad no es necesario tener cerrado el cronograma
de proyecto. Sin embargo, una vez definidas las actividades de calidad y los
paquetes de trabajo a los que se asocia, se deberán incorporar en el cronograma
para que estén programadas.
Es la distribución de la ejecución de las tareas y su avance, a lo largo del proyecto,
tal y como ha sido aprobada en su inicio o modificada en el desarrollo del pro-
yecto. El project manager deberá consultarla para definir el tiempo disponible
para las tareas de calidad y cuándo deben realizarse.
Se observa una clara iteración en este ejemplo: por una parte, necesitamos tener
definidas las actividades de calidad para incluirlas en el alcance e incluirlas en el
cronograma, pero también necesitamos tener el cronograma del proyecto defi-
nido para programar las actividades de calidad.
• La línea de base de coste, que será entrada para este proceso pero también reci-
birá los resultados del mismo (costes de las actividades de calidad a incorporar a
la línea de base de costes).
Es la distribución de costes a lo largo del proyecto, tal y como ha sido aprobada
en su inicio o modificada en el desarrollo del proyecto y los avances de su cum-
plimiento. A este documento se añadirá el presupuesto asignado a calidad.
También se observa una clara iteración en este ejemplo: por una parte, necesi-
tamos tener definidas las actividades de calidad para incluirlas en el presupuesto,
pero también puede darse el caso de que necesitemos tener el presupuesto para
calidad definido para definir las actividades de calidad a llevar a cabo.
También podrán ser de utilidad otros planes de gestión que contribuirán a la calidad
global del proyecto y pueden hacer ver áreas a tener en cuenta en término de calidad.
Documentos del proyecto (Project documents)

Entre otros documentos, nos interesarán especialmente,
Registro de interesados (Stakeholders register)

De ella se seleccionará el grupo de interesados que participará en la definición de
calidad, en su ejecución y supervisión, y que podrá participar o deberá estar informado
para, si procede, tomar decisiones que tengan un interés particular o un impacto en la
calidad final.

Contiene las amenazas y oportunidades priorizadas y con su correspondiente Plan
de Respuesta para que, en caso de que sean necesarias, puedan activarse. Este registro
de riesgos nos ayudará a identificar aquellos elementos o momentos en que la calidad

puede verse afectada. Puede darse el caso que al haberse identificado un riesgo asociado
a determinadas tareas críticas se intensifiquen las labores de aseguramiento y control de
calidad.
Documento de Requisitos (Requirements documentation)

En ella se recogen los requisitos que debe cumplir el proyecto y el producto para
satisfacer las necesidades de las partes interesadas, entre ellas las del cliente. Servirán para
que el project manager y su equipo sepan que requerimientos deben cumplirse y definir
las actividades de aseguramiento y control que aseguren su cumplimiento.
Registro de supuestos
El registro de supuestos (Assumption log) que recogerá los supuestos y restricciones
relativas a la calidad a tener en cuenta
Matriz de trazabilidad de requisitos

La Matriz de trazabilidad de requisitos (Requirements trazability matrix) que recoge
un resumen de los tests para verificar los requisitos.

Será responsabilidad del project manager conocer, y que las partes interesadas
conozcan y comprendan, las regulaciones de las agencias gubernamentales, reglas, nor-
mas y pautas de la empresa y condiciones de trabajo y operativas del proyecto, siempre
que afecten a los estándares de calidad que debe cumplir. Las percepciones culturales de
la organización y el entorno en el que se desarrolla el proyecto pueden influenciar en
lo que se entienda y se acepte por calidad.

En las empresas medianas y grandes suele haber ya una política de calidad escrita y
oficial que enmarca y guía las actividades de gestión de calidad. En otros casos, como
empresas pequeñas o uniones temporales de empresa, habrá que desarrollarla incluyendo
políticas, procedimientos y pautas de calidad o bases de datos históricas y lecciones
aprendidas.
Es responsabilidad del project manager conocerla, tenerla en cuenta en el desarrollo
del proyecto y, en caso de que sea necesario, completarla en aquellos aspectos que no
estén suficientemente definidos a nivel general como para su aplicación al proyecto
concreto.
El project manager y el responsable de calidad deben definir qué requisitos hay que
cumplir y cómo se va a organizar el proyecto para que así sea. Deberá hacer un análisis
coste–beneficio de la gestión de la calidad. Primero evaluarán las opciones –acciones de

prevención (formación, buenos procesos bien documentados, equipos adecuados,
tiempo para hacer las cosas bien…), las acciones de evaluación (ensayos, inspecciones,
auditorías…)– y sus costes. En segundo lugar, los compararán con los costes de la no
calidad asociados a fallos internos –re-trabajo, trabajo no aprovechable…– y fallos exter-
nos que detecta al cliente –fianzas, penalizaciones, pérdida de contratos...–.
A la hora de planificar la gestión de la calidad, el project manager y el responsable
de calidad deberán apoyarse en las partes interesadas más relevantes, miembros del
equipo y sus departamentos funcionales, para lograr un Plan de Gestión de la Calidad
realista, completo, eficiente, consensuado y aprobado, y que comprometa a todas las
parte simplificadas.
Se podrán ayudar de diferentes técnicas y herramientas para recoger datos, anali-
zarlos, representarlos y llegar a conclusiones y tomar decisiones.
Recogida de datos (Data gathering)

A la hora de planificar la calidad de un proyecto, se deben recoger datos que per-
mitan enfocar mejor as actividades de calidad. Los métodos de recogida pueden ser varios
pero se destacan:
• El análisis comparativo o benchmarking donde buscaremos dentro y fuera de la
organización procesos, herramientas,… que hayan sido exitosos para lograr la
calidad
• La tormenta de ideas (brainstorming) donde las personas que participen darán
ideas con una fase inicial en la que no se admiten críticas para garantizar recoger
el mayor número de ellas; en una 2ª fase se pasan a re-organizar y proceder de
igual manera.
• Entrevistas: para lograr obtener de los interesados y participantes del proyecto
sus necesidades y expectativas, requisitos explícitos e implícitos,…

Análisis coste-beneficio
A la hora de planificar la calidad de un proyecto, se debe realizar un análisis coste-
-beneficio comparando los costes de su implantación con los beneficios de entregar un
producto de calidad a tiempo y las consecuencias económicas negativas (y también de
mala imagen o pérdida de confianza ante el cliente) de cometer errores en el proyecto.
Los beneficios de la calidad (o los costes de la no calidad si hay errores) son difíciles
de cuantificar pero podemos considerar que son:
• La satisfacción de las partes interesadas.
• Los costes de prevención que serán menores que los de corrección –cuanto más
tarde se detecten los errores, mayor será el impacto sobre el proyecto y mayores
los costes de la no calidad–.
• La productividad será mayor –menor si se debe detener el proyecto para revisar

el origen de los fallos, rehacer trabajos…–.
El project manager, con los condicionantes ambientales de la empresa, debe decidir entre
invertir en mejorar la calidad del producto y asumir los costes previsibles de la no calidad.
Coste de la calidad (Cost of quality, CQ)

El coste de la calidad es el incurrido al diseñar, implantar, monitorizar y ejecutar un
Plan de Calidad para un proyecto que asegure que se cumplen los requerimientos del
cliente. Incluye:
• La revisión de estándares.
• La elaboración de informes.
• Las reuniones para identificar las causas de los fallos.
• La selección de la alternativa más adecuada para solucionarlos.
Pero este coste puede incluir muchos más si no se hacen las cosas correctamente:
costes de correcciones, pérdidas de pedidos de clientes…
En la tabla siguiente se hace una clasificación que permite clarificar estos costes:
Costes de NO Conformidad Costes de Conformidad
Costes de fallos internos Costes de prevención
Costes de fallos externos Costes de evaluación
Costes de prevención: Son los asociados con el trabajo implícito necesario para satis-
facer los requerimientos del producto o servicio demandado por el cliente y entregárselo
sin defectos. Estos costes son los de planificación de la calidad, formación, revisión del
diseño, costes de auditores…
Costes de evaluación: Son los debidos a las inspecciones, ensayos y trabajos que se
deben realizar para comprobar que el producto cumple las especificaciones y requeri-
mientos establecidos.
Costes de fallos internos: Son los costes de corrección, ajuste, parada…, debidos a la
detección de errores durante el tiempo en el que el producto o servicio está en las
instalaciones de la organización.
Costes de fallos externos: Son los referidos a los fallos en la calidad que detecta el
cliente al recibir el resultado de nuestro trabajo. Son los más importantes ya que afectan
no solamente a los trabajos de corrección, revisión…, sino también a los futuros pedidos
que puedan perderse por la desconfianza generada en el cliente.
Toma de decisiones (Decisión making)

Se deberá buscar la metodología, participantes y técnicas que permitan una toma de
decisiones rápida y efectiva y que recoja los puntos de vista de las personas más relevantes
en esa área.
Se deberá valorar cómo se ponderan las opciones, cómo se priorizan, cómo y quién
acaba tomando la decisión final.
Representación de datos (Data representation)

Diagrama de causa-efecto, espina de pez o Ishikawa (Fishbone Diagram)
Los diagramas causa-efecto ayudan a pensar sobre todas las causas reales y potenciales
de un suceso o problema, y no solamente en las más obvias o simples. Además, son
idóneos para motivar el análisis y la discusión grupal, de manera que cada equipo de
trabajo pueda ampliar su comprensión del problema, visualizar las razones, motivos o
factores principales y secundarios, identificar posibles soluciones, tomar decisiones y,
organizar planes de acción.
El diagrama causa-efecto es llamado usualmente diagrama de «Ishikawa» porque fue
creado por Kaoru Ishikawa, experto en dirección de empresas, interesado en mejorar
el control de la calidad. También es llamado «Diagrama Espina de Pescado» por su forma
similar al esqueleto de un pez.
Está compuesto por un recuadro (cabeza), una línea principal (columna vertebral),
y 4 o más líneas que apuntan a la línea principal formando un ángulo aproximado de
70º (espinas principales). Estas últimas poseen a su vez dos o tres líneas inclinadas (espi-
nas), y así sucesivamente (espinas menores), según sea necesario.
Diagramas de flujo (Flow charts)

Son representaciones gráficas de un proceso. Indica las etapas del proceso y las acti-
vidades implicadas en cada una, las relaciones entre ellas y los puntos de decisión. Pueden
ayudar al equipo a anticipar los puntos o momentos donde puede haber problemas o
deben establecerse los controles de calidad y de decisión. En el siguiente diagrama de
flujo se describe cómo recibir, registrar una solicitud de trabajo, evaluarla y decidir si se
ejecuta y, en caso afirmativo, quién la realiza, revisa y entrega al cliente.
Modelos lógicos de datos (Logical data models)

Son representaciones visuales de los datos de una organización. Pueden ser valiosos
para saber de dónde pueden venir problema de integridad y calidad de los datos,…
Histogramas (Histograms)
Es básicamente la presentación de una serie de medidas clasificadas y ordenadas en
un gráfico en el que en el eje «x» se presentan los valores posibles y en el eje «y» la
frecuencia de ocurrencia de cada uno.
El histograma se usa para:
• Obtener una comunicación clara y efectiva de la variabilidad del sistema.
• Mostrar el resultado de un cambio en el sistema.
• Identificar anormalidades examinando la forma.
• Comparar la variabilidad con los límites de especificación.
Diagrama de Pareto (Pareto’s Chart)

Es una herramienta que se utiliza para priorizar los problemas o las causas que los
genera.
El nombre de Pareto fue dado por el Dr. Juran en honor del economista italiano
Vilfredo Pareto (1848-1923), quien realizó un estudio sobre la distribución de la riqueza,
en el cual puso de manifiesto como la minoría de la población poseía la mayor parte de
la riqueza y la mayoría de la población poseía la menor parte de la riqueza. El Dr. Juran
aplicó este concepto a la calidad, obteniéndose lo que hoy se conoce como la regla
80/20.
Según este concepto, si se tiene un problema con muchas causas, podemos decir
que el 20% de las causas provocan el 80% de los problemas por lo que actuando sobre
ese 20% resolvemos el 80% de los problemas.

Es una herramienta que permite identificar lo poco vital dentro de lo mucho que
podría ser trivial. Por ejemplo, puede ayudar a identificar los tipos de errores que se
producen con más frecuencia, o las partes del proceso en las que los costes de no con-
formidades son mayores.
Para determinar las causas de mayor incidencia en un problema se traza una línea
horizontal a partir del eje vertical derecho, desde el punto donde se indica el 80% hasta
su intersección con la curva acumulada. De ese punto se traza una línea vertical hacia
el eje horizontal. Los ítems comprendidos entre esta línea vertical y el eje izquierdo
constituyen las causas cuya eliminación resuelve el 80% del problema.
Gráficos de control (Control Charts)

Se utilizan para estudiar la variación de un proceso y determinar a qué puede obe-
decer esta variación.
Un gráfico de control es una gráfica lineal en la que se han determinado estadísti-
camente un límite superior (límite de control superior) y un límite inferior (límite infe-
rior de control) a ambos lados de la media o línea central. La línea central refleja el
producto del proceso. Los límites de control proveen señales estadísticas para que la
administración actúe, indicando la separación entre la variación común y la variación

especial.
Estos gráficos son muy útiles para estudiar las propiedades de los productos, los
factores variables del proceso, los costes, los errores y otros datos administrativos. Un
gráfico de Control muestra:
• Si un proceso está bajo control o no.
• Indica resultados que requieren una explicación.
Define los límites de capacidad del sistema, los cuales, previa comparación con los
de especificación, pueden determinar los próximos pasos en un proceso de mejora.
Diagramas Matriciales (Matrix Diagrams)

Ayudan a ver la importancia de las relaciones entre factores, causas y objetivos que
existen entre los datos de las filas y las columnas de la matriz. Ayudan a identificar cuáles
son las métricas más importantes para evaluar el éxito del proyecto. Pueden ser de dife-
rentes tipos:
Diagrama Matricial en L
Es el Diagrama Matricial básico, se utiliza para representar relaciones entre dos tipos
distintos (A, B) mediante una disposición en filas y columnas.
Diagrama Matricial en A
Este modelo de diagrama es un caso particular del Diagrama Matricial en «L». Se
utiliza para representar las relaciones entre los factores que componen un tipo determi-
nado (A).
Diagrama Matricial en T
Es la combinación de dos Diagramas Matriciales en «L». Se utiliza para representar
las relaciones entre tres tipos de factores distintos (A, B y C) agrupándolos de la siguiente
forma:
- Relaciones entre el tipo A y el tipo B.
- Relaciones entre el tipo A y el tipo C.
Diagrama Matricial en Y
Es la combinación de tres Diagramas Matriciales en «L». Se utiliza para representar
las relaciones entre tres tipos distintos (A, B y C) agrupándolos de la siguiente forma:
• Relaciones entre el tipo A y el tipo B.
• Relaciones entre el tipo B y el tipo C.
• Relaciones entre el tipo C y el tipo A
Diagrama Matricial en X
Es la combinación de cuatro Diagramas Matriciales en «L». Se utiliza para representar
las relaciones entre cuatro tipos diferentes (A, B, C y D) agrupándolos de la siguiente
forma:
• Relaciones entre el tipo A y el tipo B.
• Relaciones entre el tipo B y el tipo C.
• Relaciones entre el tipo C y el tipo D.
• Relaciones entre el tipo D y el tipo A.
Las aplicaciones de este tipo de diagrama en la práctica son muy limitadas y un
ejemplo de aplicación podría ser el análisis de relaciones, en los sistemas electrónicos de
proceso de datos, entre las funciones de gestión, acciones de gestión, datos de entrada
y datos de salida.
Diagrama Matricial C
Se utiliza para representar las relaciones entre tres tipos distintos (A, B y C), teniendo
en consideración tres puntos de vista simultáneamente.
Este tipo de diagrama presenta dificultades, tanto a nivel gráfico, como a nivel con-
ceptual.
Mapas mentales (mind mapping)

Un mapa mental es un diagrama usado para representar palabras, ideas, tareas,
dibujos, u otros conceptos ligados y dispuestos radicalmente alrededor de una palabra
clave o de una idea central. Los mapas mentales son un método muy eficaz para extraer
y memorizar información.
Los mapas mentales son un método muy eficaz para extraer y memorizar informa-
ción. Son una forma lógica y creativa de tomar notas y expresar ideas que consiste,
literalmente, en cartografiar sus reflexiones sobre un tema.
Todos los mapas mentales tienen elementos comunes. Cuentan con una estructura
orgánica radial a partir de un núcleo en el que se usan líneas, símbolos, palabras, colores e
imágenes para ilustrar conceptos sencillos y lógicos. Permiten convertir largas y aburridas
listas de datos en coloridos diagramas, fáciles de memorizar y perfectamente organizados,
que funcionan de forma totalmente natural, del mismo modo que el cerebro humano.
Entre sus características están:
• La idea, el asunto o el enfoque principal se simboliza en una imagen central.
• Los temas principales irradian de la imagen central como «bifurcaciones».
• Las bifurcaciones incluyen una imagen o palabra clave dibujada o impresa en su
línea asociada.
• Los temas de menor importancia se representan como «ramas» de la bifurcación
oportuna.
• Las bifurcaciones forman una estructura de nodos conectados.
Plan de ensayos e inspecciones (Test and Inspection planning)

El project manager con su equipo decide cómo testear e inspeccionar los productos
para lograr cumplir las expectativas y requisitos de los interesados. Estos ensayos depen-
den de la industria en la que se desarrolle el proyecto (software, aeronáutica, ingeniería
civil,…)
Implicarán seleccionar una muestra aleatoria y representativa del conjunto de pro-
ductos, elementos producidos…, para determinar si cumplen con los requerimientos
del cliente. Mediante técnicas estadísticas y en función del tamaño de la muestra y la
variabilidad de los productos, se obtienen valores de la probabilidad de que un producto
sea defectuoso.
El project manager mantendrá reuniones con el equipo de proyecto, responsable de
calidad y partes interesadas más relevantes para definir las métricas adecuadas, seleccionar
las actividades de calidad más eficientes y garantizar, en definitiva, que se gestiona el
cumplimiento de todos los requerimientos.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtienen:
Plan de Gestión de Calidad (Quality management plan)

En primer lugar, el Plan de Gestión de la Calidad que describirá cómo se van a
implementar las políticas de calidad en el contexto del proyecto, y cómo tiene previsto
el equipo de dirección del proyecto cumplir los requisitos de calidad del proyecto (y
producto).
Este plan debe ser revisado al inicio del proyecto para asegurar que las decisiones se
basan en información exacta. Los beneficios de esta revisión son, entre otros, la posibi-
lidad de que el equipo se centre en los requisitos que concentran la propuesta de valor
del proyecto y lograr así la reducción de costes asociados a aspectos no relevantes.
Este plan será entrada principal para los dos procesos siguientes:
• realizar el aseguramiento de la calidad,
• y controlar la calidad,
y para el de identificar riesgos –asociados al cumplimiento de los requisitos de cali-
dad–.
Métricas de calidad (Quality measuring)

Definido el marco general de gestión de la calidad, el equipo debe descender al
detalle y definir, para cada actividad o paquete de trabajo y, en cualquier caso, para cada
entregable, qué indicadores, listas de control..., va a utilizar para medir el resultado.
Planificar la gestión del cronograma 219
Las métricas de calidad, de acuerdo a la Project Management Institute, A Guide to

the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition, Project
Management Institute, Inc., 2017, son definiciones operativas que describen un atributo
del producto o proyecto y la forma de medirse. Al definir la métrica y los valores acep-
tables, se deberá dejar un margen, mayor o menor, según lo admita el elemento, com-
ponente o producto de desviación fuera del cual el elemento medido será rechazado.
Los indicadores y las formas de medirlos pueden ser tantos como proyectos. Algunos
ejemplos serían la frecuencia de errores, el porcentaje de actividades con sobrecoste o
fuera de plazo, la fiabilidad del producto, el número de reclamaciones o quejas de las
partes interesadas, la disponibilidad del producto…
Estas métricas nos indicarán si nuestro servicio o producto está cumpliendo los
parámetros de calidad establecidos. El project manager deberá documentar las fórmulas
utilizadas, el momento en que las realiza y con qué criterio las va a interpretar.
Estas métricas serán entradas relevantes para los procesos de:
• realizar el aseguramiento de la calidad,
• y controlar la calidad.
Actualizaciones al Plan de Dirección del proyecto (Project management plan

updates)
El resultado del proceso de planificar la calidad llevará a tener que actualizar entre
otros: el plan de gestión de riesgos, la líneas de base del alcance,…
…

El resultado del proceso de planificar la calidad llevará a tener que actualizar: el
registro de interesados (tanto en número como en expectativas), El registro de lecciones
aprendidas, La matriz de trazabilidad de requisitos, el registro de riesgos,…
3.6. PLANIFICAR LA GESTIÓN DEL CRONOGRAMA
3.6.1. Gestión del cronograma en un proyecto

Una vez elaborada la EDT y paralelamente a la elaboración del Plan de Gestión de
la Calidad, el project manager puede proceder a elaborar el Plan de Gestión del cro-
nograma y a acometer los procesos que tengan como resultado final el cronograma de
proyecto.
Que un cronograma con el que se empiece un proyecto no sea realista es respon-
sabilidad del director del proyecto. Precisamente una de las razones por las que se con-
trata un project manager es para que cumpla con la fecha de entrega y, para ello, se tome
su tiempo, emplee sus capacidades y experiencia y solicite la ayuda necesaria a su equipo
o expertos que considere oportunos y utilice el saber acumulado en la compañía a este
respecto.
El cliente o el patrocinador pueden proponer una fecha de entrega pero el buen

project manager deberá realizar el proceso que se detalla en este apartado, valorando
todas las opciones posibles y los recursos necesarios hasta lograr una fecha óptima que,
si no coincide con la definida por el cliente, llevará a un análisis conjunto y razonado
de si realmente es posible realizar el proyecto con el enfoque, presupuesto y calidad
exigidos en el plazo indicado.
Normalmente el tiempo disponible para realizar un proyecto es muy justo. Por ello
se requiere una buena planificación para conseguir que todos los participantes inicien
sus trabajos a tiempo, trabajen en el orden correcto, entreguen su trabajo en el momento
previsto y no retrasen el proyecto.
Esa es la razón para elaborar el Plan de Gestión del Cronograma del proyecto como
plan subsidiario del Plan de Dirección del Proyecto.
Por lo tanto, lo primero que debe realizar el project manager es la elaboración del
Plan de Gestión del Cronograma del proyecto que lo incluirá como plan subsidiario en
el Plan de Dirección del Proyecto.
El Plan de Dirección del Proyecto establece cómo se va a realizar el Plan de Gestión
del Cronograma. Por ello, el Plan de Dirección:
• Selecciona una metodología –ya el método de la ruta crítica (critical path met-
hodology) o el de la cadena crítica (critical chain method), como los dos más
habituales– para crear el cronograma.
• Selecciona la herramienta de planificación que se va a utilizar, sea particular o
corporativa.
• Define métricas, formatos y criterios (frecuencia, umbrales de actuación…) para
desarrollar y controlar el cronograma.
Para desarrollar el cronograma de proyecto, se utilizan las salidas de los procesos de
definir actividades, secuenciar actividades, estimar recursos y duraciones de cada acti-
vidad en combinación con una herramienta de programación para crear el modelo de
cronograma. El cronograma finalizado y aprobado será la línea de base respecto a la cual

se evaluará el desempleo del proyecto en lo que a plazos se refiere.
El Plan de Gestión del Cronograma del proyecto resultante debe contener aspectos
como:
• La metodología para crear el cronograma y el programa de gestión finalmente
seleccionados.
• La línea base del cronograma, referencia a utilizar en la supervisión y control
del proyecto.
• Las medidas de desempeño e indicadores de rendimiento que permitan detectar
desviaciones en el avance de los equipos, la duración de las tareas y los plazos
parciales y el plazo total de forma temprana.
• Planificar cómo se van a gestionar las desviaciones de tiempo respecto a la línea
base.
• Procedimientos de control de cambios del cronograma.
Entre las actividades asociadas a la gestión del cronograma cabe destacar:
• En la fase de planificación:
– La definición inicial de la planificación de la gestión del plazo –Plan de
Gestión del Cronograma–.
– La elaboración de la lista de actividades –Definir las actividades–.
– La creación del diagrama de red –Secuenciar actividades–.
– La estimación de los recursos necesarios para ejecutar las actividades (Se
realiza en el Área de Gestión de los recursos)
– La estimación del plazo de cada actividad –Estimar la duración de las acti-
vidades–.
– El cálculo del camino crítico –Desarrollar el Cronograma–.
– La creación del cronograma –Desarrollar el Cronograma–.
– Introducir nuevas actividades de control de calidad o de gestión de riesgos,
si procede, tras el Plan de Calidad y elaborar el Plan de Respuesta a los
Riesgos.
– El cierre del Plan de Gestión del Cronograma y las métricas a utilizar para
evaluar su desempeño.
• En la fase de supervisión y control –Controlar el Cronograma–:
– La gestión del plazo conforme el plan establecido.
– Las medidas de desempeño del plazo respecto a la línea de base u otras
establecidas.
– La identificación de variaciones y, si procede, la solicitud de un cambio
que:
○ Actúe sobre la causa raíz para reconducir el cronograma.
○ Solicitando el cambio mediante el proceso de gestión de cambios.
– La predicción del plazo final estimado, función de los datos a fecha actual.
El Plan de Gestión del Cronograma ayuda a suministrar procedimientos para estimar
la duración de actividades y determinar si una variable ha sobrepasado el umbral de

aceptación y hay que actuar. También define el tipo de informes y formatos a utilizar
en todo el proyecto.
En el siguiente esquema se presentan los procesos relacionados con la planificación
y gestión del tiempo en un proyecto. Los cinco primeros pertenecen al grupo de pla-
nificación y el séptimo al de supervisión y control.
En este esquema se observa cómo con las salidas de los procesos de definición de
actividades, secuenciar actividades (sequence activities), estimar los recursos de las acti-
vidades (estimate activity resources) y estimar la duración (estimate duration), utilizando
la herramienta de planificación seleccionada, se elaborará el cronograma (develop sche-
dule) que servirá como línea de base para su seguimiento y supervisión en la fase de
ejecución mediante el proceso «controlar el cronograma (control schedule)».
del PMBOK y la ISO21500 en lo que a gestión del tiempo se refiere. En el siguiente cuadro
se reflejan los procesos de PMBOK y los de ISO21500 (estos últimos en cursiva).

Planificar la gestión del tiempo Controlar el crono-
Definir actividades grama
Secuenciar las actividades (controlar el crono-
Estimar la duración de las activi- grama)
dades
Desarrollar el cronograma
(secuenciar actividades)
(estimar duración de actividades)
(elaborar el cronograma)
El objetivo y contenidos de estos procesos se sintetizan en la siguiente tabla:
Proceso mediante el cual se establece la política, procedimientos

y documentación necesaria para planificar, ejecutar y controlar
Planificar la gestión del el cronograma del proyecto.
Cronograma
(Plan Schedule manage- No existe este proceso en ISO21500 si bien se considera que forma
ment) parte de la elaboración del Plan de Dirección del Proyecto y sus Planes
Subsidiarios.
A partir de los paquetes de trabajo (work packages) de la EDT
(WBS), se identifican actividades más específicas y como resul-
tado se obtiene una lista de actividades. Esta lista será la base para
Definición de actividades el diagrama de red que se creará en el proceso siguiente.
(Define activities)
En ISO21500 este proceso forma parte de los procesos de planificación
del área de conocimiento de gestión del alcance pero los objetivos y con-
tenido son iguales.
Se identifican y documentan las dependencias entre las activi-
dades. En esta fase se va indicando qué actividades van detrás de
qué actividades y se colocan todas en el orden adecuado. El
Secuenciar las actividades resultado final es el diagrama de red que, en una imagen, nos
(Secuence activities) muestra cómo se relacionan todas las actividades entre sí.
No existen diferencias entre ISO21500 y PMBOK 6.ª Edición en lo

relativo a este proceso.
Se estima el número de períodos de trabajo que se necesitan para
completar cada actividad mediante diferentes técnicas de esti-
Estimar la duración de las mación.
actividades
(Estimate activity duration) No existen diferencias entre ISO21500 y PMBOK 6.ª Edición en lo
Se crea un calendario de actividades tomando como base las
estimaciones de duración y el diagrama de precedencias. Este
cronograma permitirá estimar la fecha de finalización del pro-

Desarrollar el Cronograma yecto y de los hitos relevantes que se hayan establecido.
(Develop schedule)
Se controlan los cambios del cronograma del proyecto (por bajos
rendimientos del equipo, mayor duración de tareas…). Con este
proceso, que se desarrolla conforme se ejecuta el proyecto, se
supervisan y controlan las variaciones sobre el cronograma pre-
Controlar el Cronograma visto y se definen y proponen los cambios necesarios para tratar
(Control Schedule) de mantener la fecha prevista de finalización.

Aunque en la tabla y esquema anterior se presentan como una secuencia, realmente

se suelen superponer e interactuar.
Por otra parte, en proyectos más sencillos la definición de actividades, la identifi-
cación de dependencias, la estimación de recursos y duración y la elaboración del cro-
nograma suelen aparecer como un proceso único que se realiza de forma rápida y sen-
cilla.
Salvo el control del cronograma, el resto de actividades se realizarán en la fase de
planificación:
• Se elaborará el Plan de Gestión del Cronograma.
• Se elaborará la Lista de Actividades.
• Se creará el diagrama de red.
• Se estimarán los recursos necesarios para ejecutar las actividades. (se realiza en
otro área de conocimiento: Gestión de los Recursos)
• Se estimará con todo ello la duración de cada actividad.
• Se calculará el camino crítico y se optimizará hasta crear el cronograma provi-
sional.
• Se incorporarán las actividades de control de calidad y de respuesta a los riesgos.
• Se cerrará la línea de base del cronograma, el Plan de Gestión del Plazo y las
métricas a utilizar para evaluar su desempeño.
Tendencias y Prácticas emergentes en Gestión de cronogramas (Trends and

emerging practices in Project Schedule Management)
Con altos niveles de incertidumbre en un mercado global altamente competitivo
donde en ocasiones es difícil de definir alcances a largo plazo, se está haciendo cada vez
más importante disponer de un marco de trabajo válido para la adopción de prácticas
desarrolladas a medida, a fin de responder las necesidades cambiantes del entorno.
La planificación adaptativa define un plan pero, parte de la base de que una vez que
el trabajo empieza, las prioridades pueden cambiar y el plan necesita reflejar este nuevo
conocimiento.
A continuación, se muestran algunas de las prácticas emergentes para los métodos
de programación de proyectos.
• Programación iterativa con un Backlog: es una forma de planificación gra-
dual basado en ciclos de vida adaptativo, como por ejemplo los enfoques Agiles para
desarrollo de productos. Los requerimientos son documentados en historias de usuario
que son priorizadas y redefinidas justo antes de su ejecución y las características del
producto son desarrollados utilizando periodos de trabajo prefijados. Este enfoque es a
menudo utilizado para desarrollar valor añadido al cliente o cuando múltiples equipos
simultáneamente desarrollar un gran número de características que tienen pocas depen-
dencias entre sí.
Este método de programación es apropiado para muchos proyectos como lo indica
el uso generalizado y creciente de ciclos de vida adaptativos para el desarrollo de pro-
ductos
El beneficio de este enfoque es que da la bienvenida a los cambios a través del ciclo
de vida de desarrollo.
• Programación bajo demanda: Este enfoque, típicamente utilizado en un sis-
tema Kanban, está basado en la teoría de las restricciones y en conceptos de programa-
ción basados en Pull procedentes de metodologías de trabajo basadas en Lean Manu-
facturing. La idea principal es limitar el trabajo en progreso del equipo, a fin de conseguir
un equilibrio ente la demanda y la capacidad de realizar entregables por parte del equipo.
La programación bajo demanda no confía en un cronograma que ha sido desarrollado
previamente al desarrollo del producto o de los incrementos de producto, por lo que
más bien extrae el trabajo de un Backlog o una pila intermedia de trabajo, para realizarlo
inmediatamente en cuanto los recursos están disponibles. La programación bajo
demanda es a menudo utilizada para proyectos que desarrollan el producto de manera
incremental y donde las tareas pueden ser relativamente similares en tamaño y alcance
o pueden ser empaquetadas por tamaño y alcance.
Consideraciones para adaptar la gestión (Tailoring considerations)

Ya que cada proyecto es único, el Project manager debe poder adaptar la forma en
que los procesos de gestión del cronograma son aplicados. Algunas consideraciones de
adaptación a tener en cuenta son:
• Enfoque del ciclo de vida: ¿cuál es el enfoque más apropiado para un ciclo
de vida que permite un cronograma lo suficientemente detallado?
• Disponibilidad de recursos: ¿Cuáles son los factores que influyen sobre las
duraciones? (p.ej: correlación entre recursos disponibles y su productividad?
• Dimensiones del proyecto: ¿Como la presencia de la complejidad del pro-
yecto, incertidumbre tecnológica, novedad de productos o el monitoreo del
progreso impactarán en el nivel de control deseado?
• Apoyo tecnológico: ¿Se utiliza ayuda tecnológica para desarrollar, guardar,
transmitir recibir y almacenar información del modelo de cronograma del pro-

yecto y si es fácilmente accesible?
Consideraciones para entornos ágiles o adaptativos

Los enfoques adaptativos utilizan ciclos cortos para emprender el trabajo, revisar los
resultados y adaptarse según sea necesario. Estos ciclos proporcionan retroalimentación
rápida sobre los enfoques y la idoneidad de los entregables, y generalmente se manifiestan
como programación iterativa y programación basada en la demanda, según se comenta
en el apartado anterior.
En las organizaciones grandes, puede haber una mezcla de pequeños proyectos y
grandes iniciativas que requieren hojas de ruta a largo plazo para gestionar el desarrollo
de estos programas utilizando factores de escala (por ejemplo, tamaño del equipo, dis-
tribución geográfica, cumplimiento normativo, complejidad organizativa y complejidad
técnica). Para abordar el ciclo de vida de la entrega completa para sistemas más grandes
a nivel de toda la empresa, puede ser necesario adoptar una gama de técnicas que utilizan
un enfoque predictivo, un enfoque adaptativo o un híbrido de ambos. La organización

puede necesitar combinar prácticas de métodos principales, o adoptar un método ya
experimentado, y adoptar algunos principios y prácticas de técnicas más tradicionales.
El rol del gestor de proyectos no cambia en función de la gestión de proyectos que
utilicen un ciclo de desarrollo predictivo o que gestionen proyectos en entornos adap-
tativos. Sin embargo, para tener éxito en el uso de enfoques adaptativos, el Project
manager necesitará estar familiarizado con las herramientas y técnicas para entender
cómo aplicarlas de manera efectiva
Pasamos a detallar cada proceso.
3.6.2. Planificar la gestión del cronograma

Este proceso tiene por objetivo establecer las políticas, procedimientos, herramientas
y documentación necesaria para planificar, elaborar, gestionar, ejecutar y controlar el
cronograma de proyecto.
Asimismo, define cómo se reportarán y evaluarán las contingencias en el cronograma
y cómo se evaluarán y aprobarán los cambios en la línea de base del cronograma.
En el siguiente esquema se sitúa este proceso dentro de su área de conocimiento y
los grupos de procesos:
En el esquema siguiente se indican las partes del proceso: entradas (inputs), técnicas
y herramientas (techniques and tools) y salidas (outputs):
En ISO21500 no existe un proceso similar explícito aunque se considera que este plan se
elabora dentro del proceso «Desarrollar los planes de proyecto».
PLANIFICAR LA GESTIÓN DEL CRONOGRAMA (PLAN SCHEDULE

MANAGEMENT)
Es el proceso mediante el cual se establecen las políticas, procedimientos y docu-
mentación para planificar, desarrollar, gestionar y controlar el cronograma del pro-
yecto y a garantizar que se cumplen tanto los plazos parciales como el plazo final.
El beneficio clave de este proceso es que proporciona guía y dirección sobre como
el cronograma del proyecto será gestionado a lo largo del proyecto.
ENTRADAS (INPUTS):
Entre la información que ayudará a elaborar este plan están el acta de constitución
–área de «gestión de la integración- en la que se definen los requisitos de aprobación
del proyecto que pueden afectar a hitos del cronograma, el plan de dirección de proyecto
– del que tomaremos el plan de gestión del alcance, y el enfoque de tipo de proyecto
predictivo, adaptativo, iterativo, etc., –los factores ambientales de la empresa –la cultura,
estructura organizativa y procesos establecidos para gestionar el cronograma– o los acti-
vos de procesos de la organización –herramientas de monitorización y reporte, infor-
mación histórica y lecciones aprendidas en otros proyectos en lo que a planificación y
gestión del cronograma se refiere, herramientas de planificación y gestión de proyectos,
plantillas existentes, procedimientos de control de cambios, …–.

El Acta de Constitución define aspectos relevantes para la gestión del cronograma
como los principales hitos del proyecto, los requerimientos de alto nivel –entre ellos,
los asociados al cumplimiento de plazos y a la comunicación con las principales partes
interesadas–.


El plan de gestión del alcance describe cómo será definido y desarrollado el alcance,
que puede proporcionar información útil y necesaria a la hora de desarrollar el crono-
grama.
El Plan de Dirección del Proyecto también incluye información relativa a la línea
de base del alcance y a riesgos asociados con las estimaciones y cumplimiento de plazos
que serán de utilidad al elaborar el Plan de Gestión del Cronograma.
Enfoque de desarrollo (Development aproach)

El enfoque de desarrollo del producto (iterativo, adaptativo, predictivo, etc.), ayu-
dará a definir el enfoque del cronograma, que técnicas de estimación emplear, cuáles
son las herramientas de programación más adecuadas, y las técnicas más indicadas para
controlar el cronograma.

A la hora de definir cómo se va a gestionar el cronograma del proyecto, habrá que
tener en cuenta la cultura y estructura de la organización (flujos de reporte y escalado
de decisiones y problemas), los procesos ya establecidos para controlar y reportar los
avances y variaciones respecto al cronograma previsto, la mayor o menor facilidad para
disponer de recursos humanos y materiales (recursos críticos que habrá que solicitar con
mayor antelación ya que puede retrasar el proyecto), los propios sistemas de autorización
de trabajos o los programas de gestión de proyectos disponibles en la organización y que
facilitarán la gestión del cronograma.
Activos de los Procesos de la Organización (Organizational process assets)

Entre estos activos estarán las herramientas de monitorización y reporte, informa-
ción histórica sobre la gestión del cronograma en otros proyectos y lecciones aprendidas
al respecto, herramientas de control del cronograma, plantillas, procedimientos de con-
trol de cambios en el cronograma...
El project manager utilizará información histórica, lecciones aprendidas de proyec-

tos anteriores y procesos comunes establecidos en la organización –metodología de
programación, técnicas y herramientas de programación, métodos de estimación,…–
para, en colaboración con el sponsor del proyecto, los miembros del equipo de proyecto,
las partes interesadas relevantes y otras personas con alguna responsabilidad en la plani-
ficación y seguimiento del cronograma, adaptar el plan de gestión del cronograma de
la organización –si existe– al proyecto concreto o para redactar una nuevo.
Juicio de expertos (Experts judgement)

Las aportaciones de los expertos en las diferentes áreas, unido a una información
histórica actualizada y útil, ayudarán a elaborar un buen Plan de Gestión del Cronograma
que recoja las lecciones aprendidas de proyectos anteriores.

El Plan de Gestión del Cronograma puede tener que elegir herramientas informá-
ticas para la mejor gestión de plazos, técnicas para mejor estimar las duraciones de cada
actividad (utilizando, por ejemplo, técnicas de simulación mediante el método de Mon-
tecarlo), y métodos para calcular las tareas críticas (decidiendo entre el método del
camino crítico o la cadena crítica…).
También puede incluir determinar cuáles son las necesidades del cronograma como
por ejemplo la duración de los periodos para la planificación gradual y con qué fre-
cuencia debe ser revisada y actualizada la programación. Es necesario mantener un
balance adecuado entre el nivel de detalle necesario para gestionar el cronograma y la
cantidad de tiempo que toma mantenerlo actualizado.
El responsable del proyecto y su equipo de proyecto deberá reunirse con el sponsor
y partes interesadas más relevantes para analizar cuáles son sus expectativas en relación
al seguimiento y reporte del avance y variaciones del cronograma, para decidir cuáles
son los mejores métodos de estimación de duraciones y de seguimiento del cronograma,
entre otras cosas.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtendrá el plan de gestión del tiempo que
incluirá la metodología y herramienta(s) a utilizarse en la definición del cronograma del

proyecto, el nivel de precisión de las estimaciones basado en el alcance de las actividades
y la magnitud del proyecto, las unidades de medida para cada recurso, los límites de
control o variación del cronograma permitida antes de tomar medidas y el escalado de
la decisión, las reglas para medir el desempeño –nivel de la EDT en el que se va a realizar
la toma de datos y el seguimiento, forma de utilizar la técnica del valor ganado,…- o
formatos de reporte, entre otros. Toda esta información servirá de entrada para el resto
de procesos de esta área.
Plan de Gestión del Cronograma (Schedule management plan)

Como resultado de este proceso se obtendrá el Plan de Gestión del Cronograma
que incluirá:
• La metodología y herramientas a utilizarse en la definición del cronograma
del proyecto.
• El nivel de precisión de las estimaciones basado en el alcance de las actividades

y la magnitud del proyecto.
• Las unidades de medida para cada recurso.
• El proceso para mantener el modelo del cronograma del proyecto.
• Los límites de control o variación del cronograma permitida antes de tomar
medidas y el escalado de la decisión.
• Las reglas para medir el desempeño –nivel de la EDT en el que se va a
realizar la toma de datos y el seguimiento, forma de utilizar la técnica del Valor
Ganado…–.
• los umbrales de control: variaciones admisibles antes de que sea necesario
tomar medidas. Los umbrales son habitualmente expresados como desviaciones
en porcentaje de los parámetros establecidos en la línea base.
• Los formatos de reporte, entre otros.
• Longitudes de releases e iteraciones: Cuando utilizamos un ciclo de vida
adaptativo, consiste en definir los tamaños de los periodos para releases, e ite-
raciones. El acotar estas ventanas de trabajo, ayudan a minimizar la corrupción
del alcance (scope creep), ya que fuerza al equipo a producir las funcionalidades
esenciales primero, y después otras, si el tiempo lo permite.
3.6.3. Definir las actividades

Se identifican las actividades que hay que completar para producir los paquetes de
trabajo definidos en la EDT para lo cual, cada paquete de trabajo se va descomponiendo
en elementos más pequeños para poder estimar, planificar, ejecutar y seguir su avance
y finalización en la fase de ejecución.
Para iniciar esta actividad el project manager necesitará la línea de base del alcance
y disponer de su equipo puesto que, si participan todos, el resultado será más completo,
preciso, consensuado y harán suyo el resultado final.
No siempre será posible un desglose muy detallado. Esto puede ser debido a:
• Un mal enfoque del Enunciado del Alcance del trabajo lo que llevará a una
revisión del mismo.
• Que no exista suficiente información de las actividades posteriores.
• O que la información dependa del resultado de las actividades de fases anteriores.
En los dos últimos casos, las actividades de las fases siguientes se definirán de forma
más somera y se detallarán conforme llegue el momento, lo que se denomina planifi-
cación gradual (rolling wave planning).
los grupos de procesos:
En ISO21500 existe este mismo proceso pero dentro de los procesos de planificación del
área de conocimiento de gestión del alcance pero con objetivos y contenidos similares.
Tiene también como objetivo identificar, definir y documentar todas las actividades que
deben programarse y que son necesarias para completar todos y cada uno de los paquetes de
trabajo que conforman la EDT y, por tanto, el alcance del proyecto.
Para ello, se identifican las actividades necesarias para ejecutar los paquetes de trabajo y
serán la base para la estimación de la duración y el coste de su ejecución.
Entradas Salidas
Estructura de desglose del trabajo, EDT
iDccionario de la EDT Lista de actividades
Planes de proyecto
Cambios aprobados
DEFINIR LAS ACTIVIDADES (DEFINE ACTIVITIES)

Es el proceso en el que se definen todas las actividades necesarias para completar
cada paquete de trabajo con un nivel de detalle tal que pueda estimarse el tiempo,
recursos y coste requeridos para elaborar cada entregable del proyecto.
El beneficio clave del proceso es que se descomponen los paquetes de trabajo en

actividades que proporcionan una base para estimar, programar, ejecutar, monitorizar,
y controlar el trabajo del proyecto.
ENTRADAS (INPUTS):
Para realizar esta definición se necesitarán el plan de Dirección del Proyecto, espe-
cialmente el plan de gestión del tiempo –resultado del proceso anterior–, y la línea base
del alcance –del área de gestión del alcance, documento que reúne el Enunciado del
alcance, la EDT y su diccionario– los factores ambientales de la empresa –sistema de
gestión de la información de proyectos, procesos establecidos al respecto,… – y la base
de conocimiento de lecciones aprendidas que contengan en este caso listas de actividades
de proyectos o partes de proyectos anteriores similares.


El Plan de Gestión del Cronograma, definirá entre otras cosas, cómo se va elaborar
el cronograma (la metodología), la duración de los periodos para la planificación gradual
y el nivel de detalle necesario para gestionar el trabajo.
Línea base del alcance (Scope baseline)
Como se ha señalado, incluye el Enunciado del alcance del proyecto, la Estructura

de Desglose del Trabajo y su Diccionario que, si bien explica el trabajo incluido en el
nivel de paquete de trabajo, no está enfocado a actividades, y normalmente no es sufi-
cientemente detallado para estimar bien tiempos, recursos y costes necesarios –y riesgos
asociados a la ejecución de las actividades y a las hipótesis de estimación de esos pará-
metros–.
De cara a definir las actividades se tendrán en cuenta los paquetes de trabajo, entre-
gables, restricciones y asunciones documentados en la línea base del alcance.

Entre ellos está el sistema de gestión de la información del proyecto (PMIS) que
será dónde se almacene, entre otras, la información relacionada con las actividades del
proyecto. También estructura y cultura organizacional, así como publicaciones de
información de bases de datos comerciales.

Procedimientos, directrices, instrucciones, plantillas, lecciones aprendidas de pro-
yectos anteriores relativas a la elaboración de listas de actividades.
Se procederá a descomponer los entregables y/o paquetes de trabajo de la línea de

base en las actividades necesarias para realizarlos. El resultado no son entregables sino
actividades. Y el trabajo deberá realizarse con la información histórica y la colaboración
de todo el equipo de proyecto que se responsabilizará de su parte.
En proyectos complejos y de mayor duración, puede no ser operativo descomponer
todos y cada uno de los entregables en actividades hasta no tener más información. En
estos casos se adoptará una planificación gradual que permita un nivel de definición
tanto de la EDT como de las actividades acorde a la información disponible y las nece-
sidades del proyecto.
La existencia de plantillas de listas de actividades para ejecutar los paquetes de trabajos
procedentes de proyectos anteriores, así como la colaboración y compromiso de aquellas
personas que han ejecutado o van a ejecutar esos entregables, ayudará en la definición
de actividades.

Básicamente se refiere a personas que hayan realizado proyectos o paquetes de tra-
bajo similares. Se les solicitará su opinión sobre qué actividades son necesarias para
completar el paquete de trabajo. Deben tener experiencia y conocimientos en desarrollar
enunciados del alcance del trabajo, EDTs y programación de proyectos.
Descomposición (Decomposition)
Consiste en dividir cada paquete de trabajo en actividades de menor tamaño, más

pequeñas y más manejables, llamadas actividades de calendario. Éstas representan el
esfuerzo necesario para completar un paquete de trabajo. Permiten una estimación más
exacta del tiempo necesario para realizarlas y los recursos que necesitaremos asignar.
Involucrar a los miembros del equipo en la descomposición puede proporcionar
resultados mejores y más precisos.
La mayor diferencia entre la descomposición que se realiza en este proceso y la que
se realiza al crear la EDT es que las salidas finales en el primero son actividades de
calendario, mientras que en el segundo son entregables (servicios, documentos, equipos,
productos) que conforman la EDT. En proyectos pequeños la EDT y la lista de activi-
dades se desarrollan de forma paralela.
Cuando la definición del alcance del proyecto es insuficiente se hace imposible
descomponer alguna rama de la WBS hasta el nivel de paquete de trabajo. Las actividades
utilizadas para planificar estos componentes normalmente son insuficientes para hacer
una estimación, planificación, ejecución y supervisión del trabajo. Suelen denominarse
actividades resumen (Summary Activities), paquetes de planificación (Planning Package)

o Cuentas de control (Control accounts).
Planificación gradual (Rolling wave planning)

Mediante esta técnica solamente se definen al máximo detalle las actividades que
van a realizarse en la primera fase y de las que se dispone de suficiente información. Las
actividades de fases posteriores se definen a un nivel de detalle inferior –normalmente
a nivel de hito o entregable–.
Conforme se vaya acercando su fecha de inicio o se tenga más información, se
detallarán al nivel más adecuado. Este tipo de definición solamente se realiza si no se
tienen suficientes datos. Siempre es preferible tratar de llegar al máximo detalle posible
en todo el proyecto.
Durante la planificación estratégica, por ejemplo, se puede hacer una descomposi-
ción a nivel de hitos y conforme se acercan las fases de ejecución, se procede a des-
componer los paquetes de trabajo y las actividades, pudiéndose mantener diferentes
niveles de desglose dentro de un mismo proyecto.
Las reuniones pueden ser cara a cara, virtuales, formales o informales. Asimismo,
pueden ser mantenidas con miembros del equipo o con expertos en la materia del pro-
yecto para definir las actividades que sean necesarias para completar el trabajo.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtendrá una lista de actividades, una descripción
para que los responsables de realizarlas entiendan el alcance del trabajo a ejecutar, los
atributos (características) de cada actividad –actividades relacionadas y tipo de relación,
recursos requeridos, fechas impuestas, limitaciones, hipótesis, riesgos,…- que se irán
completando con los procesos de ésta y otras áreas y la lista de hitos de proyecto –puntos
significativos del proyecto ya contractuales ya establecidos dentro del proceso de gestión
de proyectos de la propia organización-.Como resultado se realizarán los cambios nece-
sarios, surgidos a raíz de este proceso y se actualizarán los documentos del proyecto que
sean necesarios. Toda esta información servirá de entrada para el resto de procesos de
éste área.
Lista de actividades (Activity list)

Es el principal resultado y es la base para toda la estimación de tiempos y asignación
de recursos que se hará en los procesos siguientes. Abarca todas las actividades necesarias
para ejecutar todos los paquetes de trabajo del proyecto. La lista incluye, entre otros
aspectos:
• Un identificador.
• La descripción de la actividad.
Con esta información, quien tendrá asignada la tarea tenga claro qué incluye y debe
hacer y qué no incluye (porque forma parte de otra actividad o no forma parte del
proyecto) y no debe hacer.
Toda esta información servirá de entrada para el resto de procesos de esta área:
secuenciar actividades, estimar la duración de cada actividad y elaborar el cronograma.
Para proyectos que utilizan planificación gradual, o técnicas ágiles, la lista de acti-
vidades será actualizada periódicamente a lo largo del avance del proyecto.
Atributos de cada actividad (Activity atributes)

Es la descripción de en qué consiste cada tarea, las actividades que la preceden, las
actividades que la suceden, las restricciones que haya que tener en cuenta, el responsable
de realizarla así como otras descripciones y cualquier otra información sobre los recursos
y el tiempo necesario para planificarlas.
Toda esta información servirá de entrada para el resto de procesos de esta área:
secuenciar actividades, estimar recursos para cada actividad, estimar la duración de cada
actividad y elaborar el cronograma.
Lista de hitos (Milestones list)

Son eventos relevantes que no implican trabajo. Tienen duración cero. Suelen ser
fechas de finalización de entregables, puntos de decisión u otro momento importante
en el proyecto. En algunos casos, la fecha de entrega puede tener carácter contractual
con lo que este aspecto deberá quedar bien indicado. Es decir, conviene especificar
cuándo un hito es obligatorio u opcional, y cuando es de tipo externo o interno
Estos hitos pueden venir predefinidos en el Acta de Constitución elaborada por el
patrocinador, pero el propio director del proyecto puede incorporar nuevos hitos inter-
medios que le sirvan como puntos de control del avance del proyecto para no esperar
a un hito final a detectar algún resultado no deseado.
Este resultado será una de las entradas clave para el siguiente proceso «Secuenciar
actividades».
Solicitudes de cambio (Change Request)

Una vez que ya se ha establecido la línea base del proyecto, la progresiva elaboración
de entregables en actividades puede revelar trabajo que no estaba inicialmente previsto
en la línea base del proyecto. Esto puede derivar en una solicitud de cambio. Las soli-
citudes de cambio son procesadas para revisar y decidir mediante el sistema del control
integrado de cambios.
Actualizaciones al Plan para la Dirección del Proyecto (Project management

plan updates)
Cualquier cambio el plan de dirección del proyecto debería ir mediante el sistema
de control integrado de cambios, vía solicitud de cambio. Algunos componentes que
pueden requerir la solicitud de cambio para la gestión del proyecto pueden ser:
Línea base de Cronograma (Schedule baseline)

A lo del proyecto, los paquetes de trabajo son progresivamente descompuestos en
actividades. Éste proceso puede revelar trabajo que no formaba parte de la línea base del
cronograma inicial, siendo necesario un cambio a las fechas de entrega o a otros hitos
significativos del cronograma que forman parte de la línea base del cronograma.
Línea base de Coste (Coste baseline)
Los cambios a la línea base del coste son incorporados en respuesta a cambios apro-
bados en el cronograma.
Este resultado será entrada para el proceso «Secuenciar actividades».
3.6.4. Secuenciar las actividades

Una vez que se tiene el detalle de todas las actividades necesarias para realizar cada
paquete de trabajo, que, a su vez, permiten completar el proyecto, se define el orden y
secuencia en el que se van a realizar las actividades. Para ello se identifican y documentan
las relaciones entre actividades del proyecto, asegurando que se define y documenta la
secuencia lógica de trabajos necesarios para gestionar eficientemente el proyecto con-
siderando todas sus restricciones.
Cada actividad e hito, salvo las actividades inicio y fin, se deben conectar con, al
menos, una actividad predecesora y una sucesora. Es importante resaltar que las cone-
xiones o relaciones se hacen entre los elementos de menor nivel.
El siguiente esquema sitúa este proceso dentro de su área de conocimiento y de los
grupos de procesos:
En ISO21500 existe este mismo proceso con objetivos –identificar y documentar las rela-
ciones lógicas entre las actividades del proyecto– y resultados similares –la definición de todas
las dependencias darán lugar a un diagrama de red secuencia de actividades en ISO21500 con
las relaciones entre actividades y los adelantos y retrasos que hay que tener en cuenta a la hora
de elaborar un cronograma realista–.
En la tabla siguiente se presentan las entradas y salidas (no define ni técnicas ni herra-
mientas) que propone ISO21500 para este proceso:
Entradas Salidas
Lista de actividades Secuencia de actividades
Cambios aprobados
SECUENCIAR LAS ACTIVIDADES (SEQUENCE ACTIVITIES)

Es el proceso que consiste en identificar y documentar las interrelaciones entre
las actividades del proyecto definiendo precedencias entre ellas y características de las
mismas.
El beneficio clave de este proceso es que define la secuencia lógica del trabajo, a fin
de obtener la mayor eficiencia cumpliendo las restricciones del proyecto.
ENTRADAS (INPUTS):
Para secuenciar adecuadamente las actividades se tendrá en cuenta el plan Dirección

del Proyecto –especialmente el plan de gestión del tiempo y la línea base del alcance–.
Algunos documentos del proyecto – como por ejemplo: las salidas del proceso anterior
lista de actividades, atributos de las actividades – que contiene el detalle de las mismas–,
la lista de hitos, y el registro de asunciones del proyecto– todos ellos elementos que
pueden afectar a la secuenciación de actividades–.También tendremos en cuenta, fac-
tores ambientales y activos de los procesos de la organización.


El Plan de Gestión del Cronograma elaborado define la herramienta y método para
elaborar el cronograma de proyecto que, lógicamente, condicionarán la forma en que
se secuencian las actividades.

La EDT del proyecto, los entregables, restricciones, y asunciones documentadas en
la línea base del alcance son consideradas explícitamente mientras se está secuenciando
las actividades.

Las asunciones y restricciones almacenadas en el registro de asunciones influyen en
la forma en la que las actividades son secuenciadas, las relaciones que existen entre acti-
vidades y la necesidad de utilizar adelantos y retrasos y nos puede resaltar algunos riesgos
que pueden impactar en el cronograma.
Lista de Actividades (Activity list)

Resultado del proceso anterior, es la lista de todas las actividades necesarias para
completar el alcance del producto o servicio y del proyecto. Como se ha indicado,
puede incluir un identificador de la actividad (activity identifier) y una descripción para
que el equipo de proyecto pueda entender qué incluye y cómo se va a realizar el trabajo,
y sobre todo cuales son las relaciones a establecer entre unas y otras actividades.
Atributos de la actividad (Activity attributes)

Es una extensión de la lista de actividades (activity list) identificando atributos aso-
ciados a cada actividad: identificador, descripción de la actividad, actividades sucesoras
(successor activities) y predecesoras (predecessor activities), fechas impuestas (imposed
dates), restricciones (restrictions), asunciones (assumptions), persona responsable
(accountable team member) o lugar donde se va a realizar el trabajo.

Son las fechas que deben cumplirse para que el proyecto avance conforme a lo
previsto y se vayan resolviendo los problemas, cerrando actividades y tomando deci-
siones con antelación. Se puede distinguir entre:
• Hitos obligatorios (requeridos por contrato).
• Hitos opcionales (basados en requerimientos del proyecto, información histórica

o buenas prácticas).

Entre los factores ambientales de la empresa que pueden ser necesarios tener en
cuenta están los estándares de la industria y el gobierno, los sistemas de gestión de la
información del proyecto (Project Management Information System: PMIS), la herra-
mienta de programación o los sistemas de autorización de trabajos.

Planes de proyecto con dependencias de relaciones, procedimientos, instrucciones,
plantillas, y los repositorios de lecciones aprendidas, en los que el project manager podrá
encontrar proyectos similares o experiencias pasadas que le ayuden a definir correcta-
mente las interrelaciones entre las diferentes actividades.
Para secuenciar las actividades se suele utilizar el método de diagramación por pre-
cedencias que utiliza relaciones fin-a-inicio (la actividad sucesora no puede empezar
hasta que no acabe la predecesora), fin-a-fin (la actividad sucesora no puede finalizar
hasta que acabe la predecesora), inicio-a-inicio (la actividad sucesora no puede empezar
hasta que no empiece la predecesora) e inicio-a-fin (la actividad sucesora no puede
finalizar hasta que no empiece la predecesora).
Estas dependencias pueden ser a su vez obligatorias –definidas contractualmente,
establecidas por la legislación vigente o necesarias por la propia naturaleza del trabajo–
o discrecionales –basadas en el conocimiento, buenas prácticas y decisiones del equipo
de proyecto y que deberán documentarse por si fuera necesario modificarlas durante la
ejecución del proyecto– y externas –implican relaciones entre actividades de proyecto

y actividades que no son del proyecto y están fuera del control del equipo– o internas
–implican relaciones internas a la compañía o proyecto y normalmente están bajo con-
trol del equipo, el project manager o el sponsor–.
Asimismo, se pueden aplicar adelantos –se puede avanzarse la actividad sucesora
respecto a la predecesora– o retrasos –la actividad sucesora debe retrasarse respecto a la
predecesora–.
Activos de los procesos de la organización como plantillas de diagramas de Red de
actividades de todo o parte del proyecto procedentes de proyectos anteriores, así como
la colaboración y compromiso de aquellas personas que han ejecutado o van a ejecutar
esos entregables, ayudarán en la definición de actividades tanto en la fase inicial de oferta
como en las sucesivas de planificación gradual y ejecución.
Método de diagramación por precedencia (Precedence Diagramming Met-

hod, PDM)
También conocido como AON (Activity-on-Node), implica crear un diagrama de
red (Network Diagram) o de Interrelaciones. Muestra cómo las diferentes actividades a
ejecutar dependen unas de otras. Representa las actividades como rectángulos y sus
relaciones como flechas.
En la figura siguiente se presenta un diagrama sencillo con las actividades necesarias
para construir una casa de una planta:
Ver cómo unas tareas se relacionan con otras, ayuda a identificar qué actividades
son más importantes en cada momento.
El método de diagramación por precedencias incluye cuatro tipos de dependencias
o relaciones lógicas. Una actividad predecesora es una actividad que lógicamente viene
antes que una actividad dependiente en un cronograma. Una actividad sucesora es una
actividad dependiente que lógicamente viene después que otra actividad en un crono-
grama. Estas relaciones están definidas más abajo y se ilustran a continuación:
Tipo relación Descripción y Ejemplo.
Fin a inicio
La tarea (B) no puede comenzar hasta que la tarea (A) finalice. Por ejemplo,
supongamos que tiene dos tareas: «Construir valla» y «Pintar valla». La tarea
«Pintar valla» no puede comenzar hasta que la tarea «Construir valla» finalice.
Este es el tipo más común de dependencia.
Inicio a inicio
La tarea (B) no puede comenzar hasta que la tarea (A) empiece. Por ejemplo,
supongamos que tenemos dos tareas: «Poner cimientos» y «Alisar cemento».
La tarea «Alisar cemento» no puede empezar hasta que comience la tarea
«Poner cimientos».
Final a final
La tarea (B) no puede terminar hasta que la tarea (A) finalice. Por ejemplo,
supongamos que un cocinero tiene que emplatar un plato con varios guisos
e ingredientes. Independientemente de la duración de la elaboración de cada
uno, todos deben estar listos a la vez para ser colocados en el plato y servidos
en la mesa.
Inicio a final
Es la menos utilizada. La tarea B no puede terminar hasta que la tarea A
comience. Este tipo de dependencia se utiliza en producción «just-in-time»
o de «stock cero» para minimizar el riesgo de que una tarea termine tarde si
sus tareas dependientes se retrasan.
Dos actividades pueden tener dos relaciones lógicas a la vez (por ejemplo: comienzo-
-comienzo y final-final). Relaciones múltiples entre las mismas actividades no son reco-
mendadas, por lo que es conveniente elegir la relación que tiene el impacto más alto.
Estos diagramas son de gran utilidad e interés ya que:
• Ayudarán a realizar las estimaciones de duración de las actividades y del proyecto
total.
• Ayudan a justificar ante las partes interesadas la razón del plazo final resultante
al mostrar todas las interdependencias entre actividades.
• Son como un flujo de trabajo que va indicando cuándo puede empezar cada
actividad.
• Ayudan a comprimir el cronograma y mostrar el avance del proyecto indicando
aquellas actividades ya completadas.
Método de Diagramación de Flechas (ADM)

Aunque este método no se incluye en PMBOK® Guide – Sixth Edition, se incluye

para conocimiento del lector.
Es mucho menos utilizado que el anterior. También se conoce como AOA (Activity
on Arrow), ya que utiliza las flechas para representar actividades –mientras que el ante-
rior utilizaba los nodos para representarlas–, y usa nodos (nodes) para mostrar depen-
dencias entre actividades. En estos casos solamente se utilizan dependencias: final a inicio
(Finish-to-Start, FS).
En cualquier caso, el más utilizado es el mencionado en el apartado anterior PDM.

Ninguno de los dos anteriores PDM o ADM permiten iteraciones o ramas condi-
cionadas (por ejemplo, «y si entonces se retrasa la actividad» «Y si no es necesario con-
tratar parte del proyecto…»). Si se requiere este tipo de programación debe utilizarse
los métodos de diagramación condicionada. Dos ejemplos de este tipo son el GERT
(Graphical Evaluation and Review Tecnique) y los modelos de Dinámicas de Sistemas,
cuya descripción no es objeto de este manual ni del PMBOK® Guide – Sixth Edition,
ni del examen de certificación PMP®.
Determinación e integración de las dependencias (Dependency Determina-

tion and integration)
Las relaciones de dependencia pueden ser caracterizadas por los siguientes atributos:
obligatorios o discrecionales e internas o externas. Dos de estos atributos pueden ser

aplicados al mismo tiempo, esto es: dependencia obligatoria externa, dependencia obli-
gatoria interna, dependencia discrecional externa, o dependencia discrecional interna.
Definamos los cuatro atributos:
• Obligatorias (Mandatory): vienen definidas por la propia naturaleza del tra-
bajo (en el ejemplo del diagrama de red anterior, no podemos echar el hormigón
sin haber antes colocado al acero) o por estar establecidas en el contrato, o ser
de cumplimiento legal. A veces se utiliza la expresión «lógica dura» para este
tipo de dependencias. El equipo de proyecto determinará qué relaciones son
obligatorias durante el proceso de secuenciar las actividades.
• Discrecionales (Discretionary): son las que se definen de acuerdo a la expe-
riencia y las mejores prácticas que conocen el equipo y los expertos consultados.
A veces se utiliza la expresión «lógica blanda» para este tipo de dependencias.
Por su propia definición, se pueden modificar si se considera necesario y son
muy importantes a la hora de aplicar técnicas de compresión del cronograma.
Por ello, conviene documentar las razones de su creación para, a la hora de

modificarlas, valorar el posible impacto en el proyecto.
• Externas (External): si el proyecto depende de entregables o elementos que
debe facilitar alguien externo al proyecto y sobre las cuales el equipo de proyecto
no tiene un control directo.
• Internas (Internal): si el proyecto depende de entregables o elementos que
debe facilitar alguien interno al proyecto y sobre las cuales el equipo de proyecto
no tiene un control directo.
Adelantos (leads) y retrasos (lags)

En ocasiones, es necesario definir una relación más compleja que una simple depen-
dencia de Inicio a Fin (Start to Finish, SF). Puede especificarse un tiempo de retraso
para representar un retraso entre el fin de la tarea predecesora y el comienzo de la
sucesora. Deben siempre documentarse indicando las razones de estas decisiones.
Por ejemplo, si tiene dos tareas, «Pintar pared» y «Colgar cuadros», necesitará que
entre ambas haya un tiempo de espera para que la pintura se seque. Puede indicar un
tiempo de espera en forma de duración (por ejemplo, 1d) o como un porcentaje de la
duración de la predecesora (por ejemplo, 25%). Si la predecesora tiene, por ejemplo,
una duración de cuatro días, al especificar 1 día o un 25% el retraso entre las tareas será
de un día.
El tiempo de adelanto implica una superposición de dos tareas para que la sucesora
comience antes de que finalice la predecesora. Agregar tiempo de adelanto puede ser
útil si desea que el comienzo de la tarea sucesora se adelante. El tiempo de adelanto se
especifica como una duración negativa en valor o porcentaje (– 1 día o – 25%).
Por ejemplo, para las tareas «Construir paredes» y «Estucar paredes», puede utilizar
un tiempo de adelanto para que la tarea «Estucar paredes» comience cuando, por ejem-
plo, la tarea «Construir paredes» le falten 2 días para finalizar.
Sistema de información de gestión de Proyecto (Project management

information system)
Los sistemas de información de dirección de proyectos incluyen software de progra-
mación que tiene la capacidad de ayudar a planificar, organizar, y ajustar la secuencia
de las actividades: insertando relaciones lógicas, valores de adelantos y retrasos, y dis-
tinguiendo los distintos tipos de dependencias.
SALIDAS (OUTPUTS):
Se obtiene el diagrama de red del cronograma de proyecto que es una representación

gráfica de las relaciones lógicas o dependencias entre las actividades del cronograma de
proyecto y que será entrada principal para el proceso de desarrollar el cronograma.
Además, se actualizarán algunos documentos de proyecto afectados por este proceso,
como listas de actividades, atributos de actividad, lista de hitos y registro de asunciones.
Diagramas de red del Cronograma del Proyecto (Project Schedule network

diagrams)
El resultado principal será una representación esquemática de las actividades y las
dependencias o relaciones lógicas entre sí que se denominará diagrama de red –como
el ejemplo anterior de la construcción de la casa, aunque normalmente mucho más
complejos–.
Suele ser importante añadir como anexo una descripción del proceso seguido y de
la justificación de aquellas relaciones que, por no obvias o habituales, conviene dejar
claras las razones por las que se han definido las interrelaciones.
Esta salida será entrada para el proceso de elaborar el cronograma.

Podrá ocurrir que durante la elaboración de la secuenciación salgan a la luz nuevas
actividades necesarias para completar el paquete de trabajo y el proyecto correctamente.
Por ello, serán también resultados de este proceso las actualizaciones de algunos de
los documentos que se elaboraron en el proceso anterior como la Lista de actividades,
el registro de riesgos, los atributos de las actividades, lista de hitos…
3.6.5. Estimar la duración de las actividades

En este proceso se establecen las cantidades de períodos de trabajo (horas, días,
semanas) estimadas como necesarias para realizar cada actividad con los recursos inicial-
mente asignados.
Se estimará con la mayor precisión posible el número de períodos de trabajo nece-
sarios para completar cada una de las actividades del proyecto teniendo en cuenta los
recursos disponibles, obteniéndose así la cantidad de tiempo que llevará ejecutar cada
actividad, dato imprescindible para elaborar un cronograma realista.
Como en otros parámetros de gestión del proyecto, se realizará una planificación
gradual (rolling wave planning) ya que en las fases más inmediatas se tendrá información
más detallada que dará lugar a estimaciones más precisas, mientras que en actividades
correspondientes a fases posteriores (más aún, dentro de un plan estratégico) serán más
generales y con menos precisión.
Para estimar adecuadamente la duración, los que vayan a estimarla –preferentemente
quienes van a realizar el trabajo– necesitarán conocer los requerimientos de recursos por
actividades, los calendarios de los recursos, datos históricos sobre el rendimiento de los
equipos, la duración de las actividades en otras ocasiones, la metodología que suele seguir
la compañía, la cultura de la empresa y sus sistemas de gestión de personal.
Utilizar la estrategia de incluir «colchones (pads)» en las actividades para así curarse
en salud ante la dirección es una práctica desaconsejada porque desacredita al propio
project manager, su equipo y la empresa.
Por tanto, una vez definidas todas las actividades, su interrelación y conociendo los
recursos disponibles, se define la duración de cada actividad individual. Este proceso
parte del cálculo de la cantidad de esfuerzo necesaria para realizar una actividad (30
personas*día, por ejemplo) y el número de recursos disponibles (2 personas a jornada

completa) para determinar la cantidad de períodos de trabajo necesarios para completarla
(30 personas*día/2= 15 días).
En todo momento al hablar de duraciones estimadas nos referiremos no a los esfuer-
zos de trabajo –horas o días dedicados por el equipo a una actividad– sino los días que
llevará realizar la tarea. Como en el caso anterior, una actividad puede durar 4 días,
siendo necesario el trabajo de 3 personas trabajando tres días completos cada una. La
duración estimada de la actividad es de 4 días mientras que el esfuerzo estimado es de 9
días (tres personas por tres días de dedicación cada una).
Es muy importante documentar todos los cálculos e hipótesis de partida para la
estimación de la duración inicial de manera que, si cambian las condiciones, se pueda
revisar los cambios que van a implicar y, en caso de que sea un tercero quien finalmente
lleve el proyecto, tenga la información para revisar, validar y actualizar si procede.
Las estimaciones de duración y la documentación relativa se utilizarán como entradas
en la identificación de riesgos durante el Plan de Gestión de Riesgos (por ejemplo:
asunciones o restricciones consideradas en la estimación).
El esquema siguiente sitúa el proceso de estimar la duración de actividades dentro
de su área de conocimiento y el grupo de procesos en que está:
En el siguiente esquema vemos el proceso con los datos de partida (inputs) –prác-
ticamente todos procedentes del proceso de estimación de la asignación de recursos– y
las técnicas y herramientas (techniques and tools) que se van a utilizar para los lograr los
resultados previstos (outputs): las estimaciones de duración de cada actividad (activity
duration) y las actualizaciones a documentos previamente elaborados al haber detectado
algún nuevo dato que afecte a lo ya planificado.
En ISO21500 existe este mismo proceso con objetivos y resultados similares.

También en ISO21500 tiene como objetivo estimar el tiempo necesario para completar
cada actividad del proyecto. Subraya la ISO21500 que la duración de las actividades depende
de la cantidad y tipo de recursos disponibles, la relación entre las actividades, capacidades o
curvas de aprendizaje entre otros aspectos. Resalta que la duración de las actividades suelen
resultar de un equilibrio y una negociación entre las restricciones de plazos y la disponibilidad
de recursos.
Las estimaciones de duración ayudarán a elaborar el cronograma pero si éste no permite
cumplir los plazos establecidos será necesario ajustar las duraciones, ya incorporando más o
mejores recursos, ya reduciendo los riesgos asociados a su ejecución.
Entradas Salidas
Lista de actividades
Requisitos de recursos
Estimación de la duración de las

Datos históricos actividades
Estándares de la industria
Cambios aprobados
ESTIMAR LA DURACIÓN DE LAS ACTIVIDADES (ESTIMATE ACTI-

VITY DURATION)
Este proceso que consiste en definir la cantidad de períodos de trabajo necesarios
para finalizar cada actividad con los recursos estimados. A partir de la información
obtenida sobre cada actividad y de los recursos asignados se trabaja con el equipo para
estimar la duración de la actividad.
El beneficio clave de este proceso es que proporciona la cantidad de tiempo que

llevará completar cada actividad.
ENTRADAS (INPUTS):
Para esta estimación se utilizarán algunos documentos del Plan de Dirección de

Proyecto, como por ejemplo: el plan de gestión del cronograma –que indicará el método
de estimación y nivel de precisión a utilizar–, y la línea base del alcance– que nos pro-
porciona la estructura de desglose de trabajo (EDT), el Diccionario de la EDT y el
enunciado del alcance del trabajo –donde se incluyen las hipótesis y restricciones del
proyecto que pueden afectar a la duración de las actividades–. También utilizaremos
algunos de los documentos del proyecto como, por ejemplo: la lista de actividades y sus
atributos, los requisitos de recursos para cada actividad y el calendario de recursos –ya
que su mayor o menos disponibilidad afectará a la duración de la actividad–, y el registro
de riesgos –donde pueden recogerse riesgos asociados a las actividades y su duración–.
Si, además, la organización mantiene actualizados sus activos de los procesos de la
organización –estimaciones, medidas de productividad y datos reales y lecciones apren-
didas de proyectos o partes de proyectos anteriores– y el project manager busca la cola-
boración y compromiso de aquellas personas que han ejecutado o van a ejecutar esos
entregables la estimación de duraciones será más realista.


El Plan de Gestión del Cronograma también define el método para estimar las
duraciones de cada actividad –dependiente de los activos de los procesos de la organi-
zación en buena medida– y el nivel de detalle requerido –dependiente de la fase del
ciclo de vida del proyecto y la información disponible–.

La línea base del alcance, incluye el Diccionario de la EDT, que contiene detalles
técnicos que puede influir en el esfuerzo y las estimaciones de las duraciones.

Lista de Actividades (Activity list)
Contiene las actividades cuya duración debemos estimar. Dependencias y otras res-
tricciones también pueden influir en las estimaciones de las duraciones.

Como se ha comentado anteriormente amplían la descripción de la actividad iden-
tificando todos los elementos que pueden influir en su desarrollo (actividades interre-
lacionadas, requisitos de recursos, adelantos y retrasos, etc...).

Son las fechas que deben cumplirse para que el proyecto avance conforme a lo
previsto y se vayan resolviendo los problemas, cerrando actividades y tomando deci-
siones con antelación. Se puede distinguir entre:
• Hitos obligatorios (requeridos por contrato).
• Hitos opcionales (basados en requerimientos del proyecto, información histórica
o buenas prácticas).
Requisitos de recursos (Resource requirements)

Es un elemento importante ya que es una lista descriptiva de los recursos que se
necesitan para realizar cada actividad. En ella se indican los recursos asignados a cada
actividad así como la disponibilidad de los mismos. No será igual asignar recursos con
mayor productividad que recursos menos experimentados con menor productividad.
Asignaciones de equipo de proyecto (Project Team assignments)

El proyecto estará constituido, cuando los recursos apropiados ya hayan sido asig-
nados al equipo.
Estructura de desglose de recursos (Resources breakdown structure)

La RBS es una estructura jerárquica de los recursos identificados para ejecutar el
proyecto, organizados por categoría y tipo de recurso.
Calendario de recursos (Resource calendar)

Indica la disponibilidad de los recursos. Dependiendo del tipo, calidad y cantidad
de los recursos disponibles en cada momento, la duración puede cambiar sustancial-
mente.

El registro de riesgos contiene estrategias de respuesta que pueden afectar al alcance
del proyecto tales como por ejemplo reducir o cambiar el alcance del proyecto y pro-
ducto, para evitar o para mitigar un riesgo.

Las asunciones y restricciones almacenadas en el registro de asunciones pueden
poner de manifiesto riesgos que pueden impactar en el cronograma.
Registro de Lecciones aprendidas (Lesson learned register)

Lecciones aprendidas al inicio de proyecto, pueden ser útiles a la hora de estimar
esfuerzos o duraciones para aplicarlas a fases posteriores del proyecto, y así mejorar la
exactitud y previsión de dichas estimaciones.

El entorno organizativo y cultural en el que se desarrolla el proyecto afecta lógica-
mente a la duración de las actividades. Otras posibles: bases de datos de estimaciones,
información comercial publicada y localización de miembros del equipo. El project
manager deberá hacer acopio de información e informes de proyectos anteriores para
ver los rendimientos, las problemáticas asociadas al trabajo en equipo y la eficacia a la
hora de cumplir los plazos.

Como en casos anteriores, las lecciones aprendidas de proyectos anteriores, las
metodologías y plantillas de planificación utilizadas, la información relativa a la duración
de proyectos similares, los calendarios de proyectos…, serán de gran ayuda para ejecutar
este proceso con éxito.
Dependiendo de la información y la fase de proyecto en la que nos encontremos

procederemos a hacer una estimación por analogía –estimación basada en datos histó-
ricos de proyectos similares–, paramétrica –utilizando ratios de productividad que rela-
cionen la duración con uno o varios parámetros del proyecto– o por tres puntos o PERT
–utilizando un valor probable, uno pesimista y otro optimista y calculando la media
ponderada de estos tres valores– contando a su vez con la colaboración y compromiso
de aquellas personas que han ejecutado o van a ejecutar el trabajo.
Además, deberán analizarse los datos disponibles, mediante análisis de alternativas
de las distintas opciones disponibles, Del análisis de riesgos puede derivarse la necesidad
de reservas de contingencias asociadas a riesgos previstos en la duración de actividades
o paquetes de trabajo, planificables, que hayan sido aceptados y para los que se han
desarrollado medidas de mitigación y/o contingencia. Conforme avance el proyecto y

haya más información, estas reservas pueden reducirse o eliminarse. También pueden
definirse reservas de gestión para riesgos imprevistos y no planificables.
Estimando duraciones, el Project manager con su equipo deberá tomar decisiones
consensuadas sobre los valores a asignar a dichas duraciones, para lo que es fundamental
que el equipo esté involucrado y utilizar formas de estimar que permitan la participación
del equipo.

Experiencia aportada por individuos o grupos con conocimiento especializado o
formación en desarrollo, control y gestión de cronogramas, expertise en estimaciones o
conocimientos en la disciplina o su aplicación.
Si el project manager va a estimar la duración de la ejecución de un Plan de For-
mación para la empresa y pregunta a tres empresas consultoras, potenciales proveedores
del contrato, cuál es su mejor estimación, estará utilizando esta técnica.
Estimación análoga (Analogous estimating, Top-Down)

Mediante esta técnica se realizan estimaciones (de plazo o coste) basándose en pro-
yectos similares y utilizando sus resultados con ciertos parámetros de corrección que
tengan que ver con la diferencia de recursos asignados, la experiencia de uno y otro
equipo…
Algunos ejemplos de los atributos a utilizar para corregir la estimación pueden ser:
duración, presupuesto, tamaño, complejidad, y se comparan en uno y otro proyecto,
para obtener la estimación
Tratará de utilizar, por ejemplo, las duraciones de una serie de proyectos similares
realizados por la empresa en los últimos años. Los valores se obtendrán, aparte de infor-
mación histórica como la del ejemplo, de la opinión de expertos o de project managers
que hayan participado en esos proyectos.
Se utiliza cuando hay poca información disponible, pero puede ser un buen método
siempre que los proyectos sean similares y la experiencia y preparación del equipo sean
comparables. Es un tipo de estimación rápida y menos costosa que otras, pero también
es menos precisa.
Un project manager realizará una estimación por analogía cuando tiene que tramitar
un nuevo proyecto de energía termo-solar en Grecia y desconoce cuáles son los trámites
y la duración de los mismos. Al no tener experiencia propia ni datos detallados, pregunta
a un compañero que desarrolló una infraestructura similar en el mismo país. Como el
proyecto no es exactamente igual aplicará, por ejemplo, un factor de incremento por
ser una zona más alejada y con mayores desniveles.
Estimación paramétrica (Parametric estimating)

Es una técnica de estimación en la que por medio de un algoritmo se calcula la
duración (o también el coste, tal como veremos en el siguiente área) a partir de infor-
mación histórica y parámetros de proyectos.
Esta técnica es muy similar a la anterior, si bien se realiza a través de hojas de cálculo
o programas más complejos en los que se introducen relaciones estadísticas entre los
datos históricos y otras variables (Por ejemplo: ml de tubería puesta en obra) e hipótesis
de distribución de los valores del parámetro (coste, duración…).
El resultado se obtendrá multiplicando la cantidad de trabajo (metros lineales de
tubería puesta en obra contratados) por la duración (en valor medio, intervalos de con-
fianza…) del parámetro (duración, coste…).
Para calcular las relaciones se puede utilizar:
• Las regresiones lineales, que dan el parámetro que relaciona linealmente la
variación de dos variables, una llamada dependiente y otra independiente.
• La curva de aprendizaje que ajustará los valores anteriormente obtenidos de
manera que los equipos o elementos ejecutados al inicio tendrán una duración
superior a los siguientes.
Estimación por tres valores (Three-point estimate)

Este método, consiste en solicitar al equipo de trabajo o expertos externos tres esti-
maciones:
• Una optimista (Optimistic tO): cuál es la menor duración menor posible de una
actividad si todo evoluciona conforme a lo previsto y no sólo no hay ningún
contratiempo, sino que surgen oportunidades y adelantos que, si bien posibles,
no suelen ser frecuentes.
• La más probable (Likely tL): que puede ser la duración habitual obtenida de los
últimos proyectos que han ido razonablemente bien sin grandes contratiempos
ni grandes oportunidades de adelanto.
• Una pesimista (Pessimistic tP): en la que todas aquellas cosas que pueden retra-
sarse –una tramitación administrativa, por ejemplo– se retrasan. El peor esce-
nario posible.
Si suponemos que la distribución que sigue la variable es del tipo Beta (también
conocida como PERT), se calculará la media esperada y su desviación típica de la
siguiente manera:
Distribución Beta (o PERT)
optimista + 4 x más probable + pesimista

Duración media estimada (DE) =
6
(pesimista – optimista) (P – 0)
Desviación típica o estándar (dt) = =
6 6
La distribución Beta (o estimación PERT) suele utilizarse cuando tenemos dispo-

nible un gran número de casos o información histórica.
Otra opción, puede ser suponer que la variable sigue una distribución triangular,
con lo que el cálculo de la media esperada se realizará de la siguiente manera:
Distribución Triangular:
optimista + más probable + pesimista

Duración media estimada (DE) =
3
La distribución triangular suele utilizarse cuando hay poca información histórica o

elementos de juicio.
Casos de estimación de diferentes elementos del proyecto es importante documentar
las hipótesis y suposiciones que han llevado a los valores optimista, esperado y pesimista
para:
• En primer lugar, justificarlos ante la dirección o el cliente.
• Y, en segundo lugar, para que queden registrados para futuros proyectos donde
esas hipótesis pueden ser similares o no y se puedan aplicar estas estimaciones
con correcciones o sin ellas.
Un ejemplo: un project manager que está encargado de la ejecución de un túnel de
500 metros. El escenario más desfavorable –si la roca es excesivamente dura– es de 820
días, el más optimista –si el material encontrado es más fácilmente excavable o llega a
tiempo una maquinaria más potente– será de 330 días mientras que el equipo, por su
experiencia considera que en 490 días lograrán completarlo.
La duración estimada será: (820 + 4*490+330)/6= 518 días
Pero, la probabilidad de que el proyecto se acabe en 518 días exactos es muy pequeña
(en realidad, es prácticamente nula). Por ello, el project manager debe trabajar con
probabilidades de que la duración se encuentre en un intervalo concreto de valores.
Para ello, lo primero que tendremos que calcular será la desviación típica, en el caso
de distribución Beta, vendría representada por la fórmula (P-O)/6 (820-330)/6 que
vamos a redondear a 80.
Ahora podemos decir que el intervalo de valores entre los que existe:
• Una probabilidad del 68,26% de que se encuentre la duración real es (DE
+dt,DE-dt).
• Una probabilidad del 95,46% de que se encuentre es (DE+2*dt, DE-2*dt).
• Una probabilidad del 99,73% de que se encuentre es (DE+3*dt, DE-3*dt).
Que, en el caso numérico que nos ocupa, para los dos casos extremos, para el 68 y
99%, los intervalos serían:
• (518+80, 518-80): Tendremos una probabilidad del 68% de que la duración
real esté entre 598 y 438.
• (518+3*80; 518-3*80): Tendremos una probabilidad del 99% de que la dura-
ción real esté entre 758 y 278.
Lo anteriormente expuesto suele referirse a una actividad concreta. En el caso de

querer calcularla para todo el proyecto, el procedimiento es el siguiente:
• Se calcula la duración más probable (con el método del camino crítico).
• Se calculan los cuadrados de las varianzas de todas las actividades críticas.
• Se suman dichos cuadrados.
• Se calcula la raíz cuadrada de dicha suma (desviación estándar del proyecto).
• Se calcula un intervalo dentro del cual estará la duración con una determinada
probabilidad –en el apartado de salidas del proceso se presentan ejemplos numé-
ricos– de la siguiente manera:
(duración más probable – desv. estándar, duración más probable + desv. estándar
del proyecto)
Dependiendo del número de desviaciones estándar que añadamos o restemos al valor
probable para calcular el intervalo de confianza, tendremos un intervalo con una pro-
babilidad mayor de acertar, pero esa variación puede ser tan grande que implique un
riesgo excesivo.
Este tipo de análisis es muy importante a la hora de elegir, por ejemplo, un tipo de
contrato u otro. Si, por ejemplo, de este análisis se deduce que la variabilidad de la
duración del proyecto o del coste total es alta, los términos y condiciones del contrato
deberán ser muy cuidadosamente estudiados para reducir estos riesgos, ya que si se
entrega tarde puede tener penalizaciones, y si es un contrato de precio fijo puede impli-
car grandes pérdidas.

Análisis de alternativas (Alternatives Analysis)
Los análisis de alternativas se utilizan para comparar varios niveles de habilidades o
capacidades recursos, técnicas de compresión de cronograma (las veremos más adelante),
diferentes herramientas (manual vs automatizado), Y con respecto a los recursos, si hacer
el trabajo internamente, alquilar o contratar. Esto permite al equipo evaluar variables
relacionadas con recursos, costes y duraciones para determinar un enfoque óptimo a fin
de cumplir el trabajo del proyecto.
Análisis de reservas (Reserve Analysis)

Es importante para el project manager relacionar la estimación con la gestión de
riesgos ya que una estimación detallada y documentada ayudará a identificar bien los
riesgos, lo que llevará a realizar un buen proceso de gestión de riesgos que, a su vez,
redundará en una reducción de la variabilidad de la duración, siendo, en definitiva, las
estimaciones más precisas y las reservas de riesgos menores, por lo que el plazo total del
proyecto será menor.
De esta manera se observa la estrecha y circular relación entre estimaciones y riesgos.
El project manager deberá hacer una reserva de tiempo para considerar los riesgos
no suprimidos tras diseñar el Plan de Respuesta a los Riesgos. Se suele realizar mediante
un proceso iterativo de tal manera que se realiza una reserva inicial, a continuación, se
implementa el Plan de Respuesta a los Riesgos y, después, se revisa la reserva inicial.

Cuando no hay suficientes datos o no suficientemente claros, se suele definir un
tiempo extra que actúa como seguro contra el riesgo de un retraso. Esta técnica conviene
utilizarla para las actividades estrictamente necesarias porque si se hace de forma siste-
mática y no justificada, el cronograma final no tendrá valor alguno.
Como se comentará al tratar de los riesgos, existen reservas de contingencia (reco-
gidas en el Plan de Respuestas a los Riesgos) y gerenciales o de gestión (para riesgos
imprevistos).
Las reservas de gestión se utilizarán para hacer frente a los riesgos imprevistos. No
están incluidas en la línea de base del cronograma, pero forman parte de los requisitos
globales del proyecto. Dependiendo de los términos del contrato, la utilización de las
reservas de gestión puede requerir un cambio en la línea de base.
Una técnica para tomar decisiones que puede ser utilizada en este proceso es la
técnica de votación.
Votación (Voting)
Un método que se suele utilizar a menudo en proyectos basados en enfoques ágiles
es el llamado puño de cinco (fist of five, o también fist to five) en esta técnica, el Project
manager pregunta al equipo para que opinen sobre su nivel de apoyo para una decisión
determinara que votarán de la siguiente forma: desde mantener desde el puño cerrado
(que indica falta total de apoyo) hasta levantar los cinco dedos (que indica total apoyo).
Si un miembro del equipo levanta menos de tres dedos, el miembro del equipo está
dando la oportunidad de discutir cualquier objeción con el equipo. El Project manager
continúa el proceso hasta alcanzar el consenso del equipo (todo el mundo levanta tres
o más de dos) o bien se ponen de acuerdo para pasar a la siguiente decisión.
El equipo de proyecto puede mantener reuniones para estimar las duraciones de las
actividades.
Un caso particular de este tipo de reuniones se produce cuando utilizamos enfoques
ágiles. En ellas es necesario mantener reuniones de planificación de los sprints (o itera-
ciones) en las que será necesario tratar la inclusión de ítems (historias de usuario) a la
cola del producto (Product Backlog) y decidir por parte del equipo, cuáles de esos ítems
(historias de usuario), van a ser incluidos en el siguiente sprint (iteración). El equipo
desglosa las historias de usuario en tareas de bajo nivel, con estimaciones en horas, y
entonces valida que esas estimaciones son alcanzables, basado en la capacidad del equipo
frente a la duración del sprint. Esta reunión normalmente semanal tiene el primer día
de la iteración (sprint) y asistirán el Responsable de producto (Product Owner), el Scrum
Master y el Project manager, junto al equipo. La salida de esta reunión incluye la pila
del sprint (Backlog sprint), así como asunciones, riesgos, dependencias, decisiones y
acciones.
SALIDAS (OUTPUTS):
El resultado de este proceso serán estimaciones de la duración de cada actividad o

paquete de trabajo que podrán darse como un valor único o, más recomendable, como
un valor medio al que se le asocia un intervalo de confianza. Estas estimaciones serán
utilizadas como entradas del proceso siguiente –desarrollar el cronograma– y del proceso
de identificar riesgos –área de gestión de riesgos del proyecto– ya que detrás de cada
estimación hay hipótesis y detrás de cada hipótesis está el riesgo de que no se cumpla.
Estas estimaciones (salida principal del proceso), se complementarán con las bases de las
estimaciones –documentación de detalle de las estimaciones realizadas–, y con la actua-
lización de los documentos del proyecto, como registro de asunciones, atributos de
actividades y registro de las lecciones aprendidas.
Estimación de las duraciones (Duration estimates)

Es el resultado fundamental de este proceso. Con la lista de actividades y sus recursos
asignados y aplicando, de entre las técnicas indicadas, la que mejor se adapte al proyecto
y sus circunstancias, se estima la duración de cada actividad.
Este resultado será un documento en forma de lista tabulada que nos indicará para
cada actividad la duración estimada (en horas, días, meses) y con las hipótesis y suposi-
ciones que se han tenido en cuenta.
Se recomienda expresarlo en valor medio, intervalos de confianza y porcentajes de
probabilidad de exceder un valor concreto de la duración, utilizando los métodos expli-
cados a continuación:
Esta salida será entrada, a su vez, para otros procesos de importancia como, por
ejemplo:
• «Desarrollar el cronograma» del área de conocimiento de gestión del tiempo.
• «Identificar riesgos» del área de conocimiento de gestión de riesgos. Nótese que
el Registro de Riesgos es una entrada para el proceso de estimación de la dura-
ción de las actividades, pero, a su vez, las duraciones de actividades son entradas
para el registro de riesgos –puede haber riesgos asociados a las estimaciones y
cumplimiento de los plazos de ejecución de las actividades y paquetes de tra-
bajos–.

La planificación es un proceso iterativo en el que, conforme avanzamos, vamos
teniendo nuevos datos, van apareciendo nuevas actividades, lo que nos llevará a tener
que actualizar documentos ya elaborados en fases anteriores.
Es por ello que, el segundo resultado de este proceso, es la actualización de algunos
documentos del proyecto como la lista de actividades, la lista de atributos, los supuestos
hechos durante la estimación o los niveles de habilidad y disponibilidad del equipo y el
registro de lecciones aprendidas, entre otros.
3.6.6. Desarrollar el cronograma

Este proceso tiene como resultado el cronograma del proyecto (project schedule).
En este proceso se analizan las secuencias de las actividades, las duraciones, los requeri-
mientos y disponibilidad de recursos y las restricciones o condicionantes en los plazos
para crear un cronograma de proyecto realista y con fechas de ejecución planificadas y
consensuadas con los responsables de ejecutarlas.
La diferencia entre la estimación de la duración de las actividades y el cronograma
es que éste último se integra en el calendario. Por ello, es importante que el equipo de
proyecto que elaboró y revisó el diagrama de red y estimó la duración de las actividades,
revise y apruebe el cronograma final por si, al ver las actividades y sus duraciones junto
con su calendario, identificaran nuevos riesgos o aspectos a tener en cuenta.
En este proceso se analizará la información resultante de procesos ya descritos:
• El Enunciado del Alcance del trabajo (project scope statement).

• El listado de actividades definidas (activity list).
• El diagrama de red (network diagram).
• Las estimaciones de duración de actividades (activity duration estimates).
• Los recursos necesarios para realizarlas (activity resource requirements).
• Y, además, los calendarios de tareas, de recursos y de la propia compañía
(resource calendars).
Toda esta información se incorporará a una herramienta de gestión de proyectos
que generará automáticamente un cronograma con fechas planificadas para iniciar y
completar cada actividad del proyecto.
Con toda esa información el project manager y su equipo (Mulcahy, 2011):
• Trabajarán teniendo en cuenta las prioridades de las partes interesadas.
• Analizarán diferentes formas de ejecutar el trabajo.
• Valorarán el impacto recíproco con otros proyectos.
• Se reunirá con los responsables funcionales para asegurar los recursos necesarios.
• Utilizará técnicas de compresión (fast-tracking, crashing o revisión del dia-
grama).
• Ajustará todos los componentes del Plan de Gestión del Proyecto.
• Nivelará recursos tratando de que la carga de trabajo sea homogénea en el
tiempo.
En definitiva, una serie importante de actividades que compartirá con su equipo y
con las partes interesadas para lograr su consenso y su implicación para, finalmente,
obtener como resultado el cronograma del proyecto aceptado y definitivo.
Algunas de estas tareas serán más fáciles con la utilización de programas de gestión
de proyectos pero otras requerirán tiempo y dedicación del equipo de proyecto y el
project manager.
En el siguiente esquema se ubica dentro de su área de conocimiento y grupo de
procesos al que pertenece:
En el esquema siguiente se sintetizan entradas (inputs), técnicas y herramientas

(techniques and tools) y resultados (outputs) de este importante proceso:
En ISO21500 existe este mismo proceso con objetivos y resultados similares. También en
ISO21500 tiene por objetivo calcular las fechas de inicio y fin de las actividades del proyecto
y establecer la línea base del cronograma del proyecto. El cronograma se establece al nivel de
actividades tales que permitan un seguimiento adecuado y eficiente del alcance del proyecto y
que permita identificar variaciones que repercutan en el cumplimiento de hitos y plazos a tiempo.
Si bien se elabora al inicio del proyecto, el cronograma evolucionará conforme avance el
proyecto, conforme cambie el Plan de Dirección del Proyecto o nuevos riesgos aparezcan.
Entradas Salidas
Secuencia de actividades
Estimación de la duración de actividades
Restricciones del cronograma Cronograma
Registro de riesgos
Cambios aprobados
DESARROLLAR EL CRONOGRAMA (DEVELOP SCHEDULE)

Es el proceso de analizar la secuencia de actividades, duraciones, requisitos de
recursos, y restricciones de calendario para crear un modelo de cronograma para la
ejecución, monitoreo y control del proyecto.
El beneficio clave de este proceso es que genera un modelo de cronograma para

completar las actividades del proyecto.
ENTRADAS (INPUTS):
Para este proceso se utilizarán todas las salidas de los procesos anteriores –el Plan de
Gestión del Cronograma, las Listas de Actividades y sus atributos que darán información
para construir el cronograma, el diagrama de red, los requerimientos de recursos, las
estimaciones de duración de las actividades–, el Enunciado del alcance del proyecto –
donde se recogen hipótesis y restricciones que pueden afectar al cronograma–, el registro
de riesgos –que recogerá todas los riesgos algunos de los cuales pueden afectar al cro-
nograma–, las asignaciones, definitivas o no, de recursos a cada actividad, la estructura
de desglose de recursos, los factores ambientales de la empresa –herramientas de pro-
gramación a utilizar– y activos de los procesos de la organización –metodología de

programación: cadena crítica, camino crítico u otra–.


El Plan de Gestión del Cronograma definirá el método y herramienta para la ela-
boración del cronograma.

La línea base del alcance, que como ya sabemos incluye el Enunciado del alcance
del proyecto, la EDT y su diccionario, contiene detalles sobre los entregables del pro-
yecto que deberán ser considerados cuando estemos generando el modelo del crono-
grama.

Lista de las actividades que se van a realizar en el proyecto y se van a incluir, por
tanto, en el cronograma, ordenadas para ayudar a asegurarse de que la lista es completa
y que no incluye actividades no requeridas o que no forman parte del proyecto.

Es una extensión de la lista de actividades proporcionando detalle de cada actividad
como su descripción, actividades relacionadas, fechas, restricciones, asunciones, res-
ponsables…que serán útiles a la hora de construir el cronograma.

La lista de hitos contiene fechas programadas para hitos específicos.
Diagramas de red del Cronograma (Project schedule network diagrams)
Muestra gráficamente cómo se relacionan las actividades entre sí y relaciones que
serán utilizadas para calcular el cronograma.
Requisitos de recursos de la actividad (Activity resource requirements)

Lista descriptiva de los recursos que se necesitan para realizar cada actividad, y en
ella se indican los recursos asignados a cada actividad, utilizados para crear el modelo de
cronograma.
Calendario de recursos (Resource calendar)

Información sobre los recursos autorizados para utilizar en el proyecto: recursos

disponibles y en qué fecha lo estarán. Esta entrada es, a su vez, salida del proceso
«Adquirir el equipo de proyecto (Adquire Project team)» que forma parte del grupo de
procesos de ejecución. Esto que puede parecer una incoherencia tiene que ver con el
hecho de que, normalmente, en un proyecto se realiza una primera asignación de
recursos en la fase de planificación (que daría lugar a la entrada «Calendario de recursos
(provisional)» y no es hasta que se inicia el proyecto cuando se pueden confirmar los
recursos que daría lugar a la entrada «Calendario de recursos (definitiva)».
Asignaciones de equipo de proyecto (Project Team assignments)

Las asignaciones al equipo de proyecto, especifican que recursos son asignados a
cada actividad.
Estimaciones de las duraciones (Duration estimates)

Documento en forma de lista tabulada que indicará la duración estimada –en horas,
días, meses y con las hipótesis y suposiciones que se han tenido en cuenta– de cada
actividad.
Base de las estimaciones (Basis of estimates)

Contiene detalles adicionales que dan soporte a las estimaciones de las duraciones.
Independientemente del nivel de detalle, el documento de apoyo debería proporcionar
una comprensión clara y completa de cómo se obtuvieron las estimaciones.
Estimaciones de la duración de la actividad (Activity duration estimates)

Documento en forma de lista tabulada que indicará la duración estimada –en horas,
días, meses y con las hipótesis y suposiciones que se han tenido en cuenta– de cada
actividad.
Enunciado del Alcance del proyecto (Project scope statement)

Del que conviene revisar y recordar las restricciones identificadas, así como las fechas
de finalización e hitos que contractualmente se deben cumplir.
Estructura de desglose de recursos

Es el esquema que recoge los diferentes recursos agrupados por tipo no debiéndose
confundir con el organigrama de proyecto.
Asignaciones de personal al proyecto (Project staff assignments)

Como ocurría con la entrada «Calendarios de recursos», esta entrada es, a su vez,
salida del proceso «Adquirir el equipo de proyecto (Adquire Project team)» que forma
parte del grupo de procesos de ejecución. Esto que puede parecer una incoherencia
tiene que ver con el hecho de que, normalmente, en un proyecto se realiza una primera
asignación de recursos en la fase de planificación, que daría lugar a la entrada «Asigna-
ciones (provisionales) de personal al proyecto» y no es hasta que se inicia la ejecución
del proyecto cuando se pueden confirmar los recursos, que daría lugar a la entrada
«Asignaciones (definitivas) de personal al proyecto».

Las asunciones y restricciones almacenadas en el registro de asunciones pueden
poner de manifiesto riesgos que pueden impactar en el cronograma.

El registro de riesgos recoge todos los riesgos identificados en el proyecto que pue-
dan afectar al cronograma. Nuevamente nos encontramos con un proceso iterativo por
el cual:
• O primero debemos hacer el cronograma para posteriormente identificar riesgos
que pueden afectar al cronograma.
• O primero identificamos riesgos asociados con el cronograma que tenemos en
cuenta al elaborarlo para, una vez elaborado, poder identificar riesgos asociados
a su cumplimiento.
Registro de Lecciones Aprendidas (Lessons learned register)

Las lecciones aprendidas obtenidas al inicio del proyecto, pueden ser de utilidad para
desarrollar el modelo de cronograma a fin de utilizarlo en fases posteriores y mejorar la
validez del modelo.
Lo veremos en el Area de conocimiento, más adelante: Los proveedores contribui-
rán al calendario del proyecto a medida que desarrollan los detalles de cómo realizarán
el trabajo del proyecto para cumplir con los compromisos contractuales.

Se tendrán en cuenta todos aquellos factores que afecten a la revisión final del cro-
nograma.
Activos de los procesos de organización (Organization process assets)

Entre los activos de los procesos de la organización están: los calendarios laborales
así como los horarios y turnos de trabajo y la herramienta de gestión de proyectos uti-
lizada ya sea particular, corporativa, comercial o propia de la compañía.
El project manager utilizará las técnicas –camino crítico, análisis de la red del cro-
nograma– así como las herramientas –software de gestión de proyectos, de gestión carga-
-capacidad,… –establecidas por la organización para desarrollar el cronograma, las téc-
nicas de optimización de recursos-nivelación de recursos, suavización de recursos–
Análisis de datos– análisis «qué pasa si», simulación– , aplicación de adelantos y retrasos,
compresión del cronograma –Intensificación o ejecución paralela– la utilización de
herramientas de programación de cronogramas habitualmente incluidas en Sistemas de
Información de Gestión de Proyecto para con todo ello y teniendo en cuenta los obje-
tivos y condicionantes del proyecto, permitan obtener un cronograma realista y que
pueda ser acordado por todas las partes interesadas relevantes.
Análisis de la red del Cronograma (Schedule Network analysis)

El análisis de la red del cronograma es una técnica general que se utiliza para generar
el modelo del cronograma del proyecto. Antes de proceder a evaluaciones más detalla-
das, se realiza un análisis del diagrama de red con sus dependencias y se revisa que no
hay ninguna actividad sin enlaces, que no hay ninguna dependencia ilógica, tareas sin
tareas que le precedan o estén conectadas a la actividad final.
Se apoya en otras diversas técnicas tales como el método del camino crítico, técnicas
de optimización de recursos, y técnicas de modelado. Todas ellas las veremos a conti-
nuación.
Algunos análisis adicionales pueden consistir, por ejemplo, en:
• Evaluar la necesidad de agregar reservas de cronograma, a fin de reducir la pro-
babilidad de un retraso del cronograma cuando múltiples caminos convergen
en un punto a la vez o cuando múltiples caminos divergen de un nodo de un
punto a la vez, para reducir la probabilidad de retraso.
• Revisar la red para ver si el camino crítico tiene actividades de alto riesgo o
actividades muy largas que podrías necesitar la utilización de reservas de cro-
nograma o la implementación de medidas de respuesta para reducir los riesgos
en el camino crítico
Método de la ruta crítica (Critical path method)

Es una de las herramientas más importantes y potentes para hacer el seguimiento de
los proyectos. Cada cronograma o diagrama de red tiene lo que se denomina ruta o
camino crítico. Lo forman el grupo de actividades relacionadas entre sí cuya duración
total es superior a la del resto. Por tanto, la suma de la duración de cada tarea nos da la
duración total del proyecto. Suelen comenzar con una actividad ficticia «Inicio» y ter-
minan con la actividad ficticia «Fin».
La característica principal de las tareas que conforman la ruta crítica (critical path)
es que si se retrasa su finalización afecta directamente a la duración final del proyecto.

Por lo tanto, son tareas que, si no queremos que el proyecto se retrase, deben comple-
tarse en plazo.
Por el contrario, si una tarea no se encuentra en ese camino querrá decir que pode-
mos admitir un retraso determinado antes de que afecte al plazo total del proyecto. Este
retraso admisible se denomina «holgura».
Este método es de gran ayuda ya que:
• Muestra y demuestra la duración total del proyecto.
• Permite centrar esfuerzos en los puntos más críticos.
• Permite identificar si alguna tarea o camino no crítico puede pasar a serlo y hay
que actuar.
• Ayuda a evaluar diferentes escenarios y ver su impacto sobre la duración.
• Permite ver qué actividades tienen holgura y, por ejemplo, asignarles recursos
menos experimentados a los que les llevará más tiempo realizarlos, pero el pro-
yecto lo puede admitir.
Identificar el camino crítico

Con el siguiente ejemplo se calcula el camino crítico con la misma metodología,
con la que lo hacen los programas informáticos de Dirección de Proyectos. Supongamos
este sencillo proyecto con 5 tareas además de las de inicio y final:
En primer lugar, se identifican los diferentes caminos posibles para acabar el proyecto
y se calcula su plazo total:
El segundo camino es el que marca el camino crítico ya que es el de mayor duración.

La duración total del proyecto será de 16 días.
Cálculo de la holgura (float)

La holgura de las tareas que están en el camino crítico es por definición cero o un
número negativo. La holgura de una tarea se define como el número de días (o semanas,
meses…) que puede retrasarse sin afectar al plazo final del proyecto.
Comenzamos con el segundo camino más largo –en nuestro ejemplo es el que tiene
una duración total de 15 días–. A cada tarea se le asigna como holgura la diferencia entre
la duración crítica y la duración de este camino: 16-15=1. Se hace lo mismo con el
tercer camino: 16-13=3.
En el caso de la actividad B, por ejemplo, nos quedamos con la holgura menor de
las que resulten de estas operaciones (en un caso es 0 y en otro caso, 1). Por lo tanto,
su holgura es 0. Como regla general, cuando una actividad esté en varias opciones de
camino, la holgura que se considera es la menor de las posibles.
Este parámetro es un dato muy importante que debemos controlar ya que se puede
utilizar para ver cómo va el proyecto y predecir dónde puede haber problemas y, de
esta manera, asignar los recursos más fiables a las tareas críticas o casi críticas.
El siguiente esquema muestra las holguras de cada actividad:
Recordamos que la holgura nos dice el número de días que una tarea puede retra-
sarse sin afectar al plazo final. En este ejemplo, la actividad D podrá retrasarse hasta 3
días. Si se retrasa un cuarto día pasarán a ser el nuevo camino crítico. Y la actividad C
podrá retrasarse un solo día sin afectar al plazo final.
Por tanto, la ruta (o rutas, puesto que puede haber más de una, incrementando el
riesgo del proyecto) crítica será la formada por la cadena de actividades con holgura cero
(o negativa, si el proyecto va retrasado).
El Camino cuasi-crítico
Habrá caminos en los que, no siendo críticos, su duración está próxima a la del
camino crítico. Esta circunstancia aumentará los riesgos del proyecto y obligará al project
manager y su equipo a estar atentos y controlar cualquier cambio o circunstancia que
lo convierta en crítico. Algunos programas de Dirección de Proyectos permiten definir
la holgura mínima admitida tal que si la holgura baja de este límite marcado el camino
aparezca también como crítico.
Otros parámetros importantes

Otros parámetros importantes a calcular, y que darán información de aspectos
importantes del cronograma del proyecto como el margen de maniobra que se tiene
para modificar el inicio de una tarea, son:
• El comienzo más temprano (Early Start Date, ES): la fecha más temprana en la
que una actividad puede empezar y que ocurrirá cuando ninguna de las tareas
que le preceden en la cadena se retrase.
• La finalización más temprana (Early Finish Date, EF): la fecha más temprana en
la que una actividad puede acabar y que ocurrirá cuando ninguna de las tareas
que le preceden en la cadena ni ella misma se retrasen.
• La fecha de inicio tardía (Late Start Date, LS): es la fecha más tardía que puede
empezar una tarea sin afectar al plazo final, la fecha tope de comienzo para que
no afecte al plazo final.
• La fecha de final más tardía (Late Finish Date, LF): es la fecha más tardía que
puede acabar una tarea sin afectar al plazo final del proyecto.
Estos datos también son de gran utilidad para, por ejemplo, poder decidir si un
recurso del proyecto puede dedicarse temporalmente a otro proyecto. Si esa persona va
a poder estar disponible antes de la fecha de inicio más tardía del proyecto (Late start
date, LS), podrá hacerlo, pero siempre conscientes de que los días que pasan desde la
fecha más temprana que puede empezar la tarea hasta la fecha que realmente se empieza,
son días de holgura que se han perdido.
Cálculo y representación de estos parámetros:
Para calcularlos se suele utilizar los métodos de avance hacia adelante (fordward pass)
para calcular los comienzos y finales tempranos de cada camino de nuestro proyecto.
Una vez realizado, se procede a realizar la misma operación, pero hacia atrás (backward
pass) para calcular el inicio y final más tardíos. En este ejemplo podemos ver la colocación
de cada parámetro:
En este ejemplo, esta tarea de duración 5 y holgura 3, no podrá comenzar antes del
5º día ni finalizar antes del 9º día, no podrá iniciarse más tarde del 8º día sin afectar al
plazo final y no podrá finalizar más tarde del día 12 sin retrasar la fecha final del proyecto.
Una vez presentados los conceptos y su representación en el diagrama, pasamos a
hacer un ejemplo sencillo que ayude a entender el criterio de cálculo que, como se ha
indicado anteriormente, los programas de Dirección de Proyectos hacen de forma
automática. Tomamos el siguiente ejemplo sencillo:
En este caso el camino crítico es el formado por Inicio-D-B-C-Final.

En primer lugar se calculan las fechas más tempranas de inicio y final desde el inicio
del proyecto hacia delante (fordward pass). Para ello, la tarea A comenzará el primer día
(día 1) y como su duración es de 5 días, acabará el quinto día (día 5). De esta manera la
actividad B no podrá empezar hasta el sexto día (día 6) y como su duración es de 4 días,
acabará el noveno día (día 9). Y así sucesivamente.
Esto sería correcto si no tuviéramos en cuenta que, como podemos comprobar, la

actividad B tiene dos tareas predecesoras –A y D– con lo que si calculamos estos pará-
metros para D obtendremos:
En este caso, como la tarea B requiere que se completen todas sus predecesoras antes
de poder iniciarse, la fecha más temprana en que podrá comenzar la actividad B será el
día siguiente a que acabe la predecesora que finaliza más tarde, en este caso la tarea B,
con lo cual la ES de la tarea B será 7, con lo que el esquema quedará de la siguiente
manera:
Como se ha comentado anteriormente, las fechas más tardías de inicio (Late start
date, LS) y final (Late Finish Date, LF) se calculan desde el final hacia atrás (backward
pass). Para lo cual, partiendo de la situación anterior, calculamos los valores de LS y LF
para la rama superior obteniendo el siguiente resultado:
Tipos de holguras
Una vez conocidos estos parámetros volvemos a las holguras para indicar que existen
tres tipos de holguras:
• Holgura total (total float)
Tiempo que una actividad puede retrasarse sin afectar a la fecha final del pro-
yecto o un hito intermedio. Se calculará como la fecha de inicio más tardía
menos la fecha de inicio más temprana ó la fecha de finalización más tardía
menos la fecha de finalización más temprana.
• Holgura libre (free float)
Tiempo que una actividad puede retrasarse sin retrasar la fecha más temprana
de inicio de la actividad que le sucede.
• Holgura del proyecto (project float)

Tiempo que el proyecto puede retrasarse sin afectar a la fecha acordada de entrega
al cliente.
Método de la cadena crítica (Critical chain method)

Este método se ha eliminado en Project Management Institute, A Guide to the Project
Management Body of Knowledge (PMBOK® Guide) – Sixth Edition, pero se deja a efectos
formativos del lector.
Otro de los métodos más usuales para elaborar el cronograma es el método de la
cadena crítica donde las restricciones de recursos se utilizan para determinar el camino
crítico. En estos análisis los recursos son bienes escasos que determinan el camino crítico.
Para ello, primero se realiza el cálculo del camino crítico, tal y como se ha explicado
anteriormente. En ese momento se asignan los recursos realmente disponibles y se
determina el resultado del cronograma con esos recursos, lo que suele resultar en un
camino crítico diferente.
Para manejar la incertidumbre se agregan colchones de duración que no implican
trabajo. Un colchón (Buffer) puede ser de proyecto –si se coloca al final de la cadena
crítica (critical chain)– o de alimentación –se colocan donde una cadena de tareas
dependientes alimenta la cadena crítica–.
Una vez determinadas las actividades del programa con estos colchones, las tareas
se planifican en función de sus fechas de inicio (Late start date, LS) y fechas de finali-
zación más tardías (Late Finish Date, LF). De esta manera, este método no gestiona la
holgura total (Total float) de los caminos de la red sino las duraciones restantes de los
colchones en función de la duración de las tareas que quedan por realizar.
Técnicas de optimización de recursos (Resource optimization techniques)

Utilizaba para ajustar el comienzo y el final de actividades a fin de ajustar los recursos
planificados y que sean iguales o menores que la disponibilidad de los recursos. Algunos
ejemplos de técnicas de optimización de recursos son:
Nivelación de recursos (Resource leveling)

Es una técnica en la que las fechas iniciales y finales de las actividades son ajustadas
en base a las restricciones de los recursos, con el objetivo de balancear su demanda con
la disponibilidad de los recursos. La nivelación de recursos puede ser utilizado cuando
algunos recursos que sean compartidos o críticos solo están disponibles en ciertos
momentos o en cantidades limitadas, por lo que cuando recurso ha sido asignado a dos
o más actividades durante el mismo período, es necesario mantener la utilización del
recurso en un nivel constante. La nivelación de recursos a menudo puede originar el
camino crítico cambia. Se utiliza la holgura disponible para hacer la nivelación de
recursos por lo que el camino crítico puede cambiar, normalmente, aumentando la
duración.
Suavización de recursos (Resource smoothing)

Una técnica que ajusta las actividades de un cronograma de forma que los requisitos
de los recursos del proyecto no excedan de ciertos límites predefinidos. En la suavización
de recursos, de manera opuesta a la nivelación de recursos, el camino crítico del proyecto
no cambia y la fecha de finalización puede no ser retrasada, ya que las actividades solo
se retrasan dentro lo que permiten su holgura total y libre. La suavización de recursos
puede no ser capaz de optimizar todos los recursos.
Análisis de datos (Data Analysis)

Análisis de escenarios ¿Qué pasa para si…?:
Siguiendo técnicas similares a las utilizadas en la identificación de riesgos, se pueden
generar diferentes escenarios y ver su impacto en el cronograma lo que permite tener
planes de respuesta para cada caso. La técnica se utiliza evaluando los impactos generados
al responder la pregunta ¿Qué pasa si se produce el escenario X?
Nos preguntaremos qué pasa si la turbina llega con una semana de retraso al parque
eólico, qué pasa si el escritor no nos entrega el manuscrito en la fecha indicada, qué pasa
si uno de los equipos de trabajo tiene un accidente y se detiene el trabajo...
Los programas de Dirección de Proyectos permiten de forma rápida y cómoda tes-
tear diferentes alternativas y situaciones para ver la sensibilidad del plazo final al cambio
de un parámetro.
Simulaciones (Simulation):
Las simulaciones implican realizar cálculos de duraciones para diferentes hipótesis y
utilizando normalmente distribuciones de probabilidad generadas a partir de las estima-
ciones por tres puntos. La técnica más habitual, dentro de que no es muy utilizada, es
el Análisis Monte Carlo.
Una forma en la que suele ser utilizada es a partir de los tres puntos de estimación
(pesimista, optimista y más probable) o conociendo la distribución de probabilidad de
la variable, calcularán la probabilidad de cumplir plazos o de que una actividad pase a
estar en el camino crítico. Todo ello teniendo en cuenta restricciones o condiciones de
contorno como que una determinada tarea acabe en una fecha determinada.
La simulación de Montecarlo implica calcular múltiples duraciones de paquetes de
trabajo, con diferentes asunciones de actividades, restricciones, riesgos, escenarios con
distintas probabilidades y otras representaciones de incertidumbre. Mediante un método
iterativo y ayudados por software específico para utilizar este método, llegaremos a resul-
tados en los que obtendremos la distribución de probabilidad de la variable que estamos
estudiando (por ejemplo: fecha final del proyecto)
Adelantos y retrasos (Leads and Lags)

Adelantos y retrasos son ajustes aplicados durante el análisis de redes para desarrollar
un cronograma viable mediante el ajuste de la fecha de comienzo de actividades suce-
soras. Adelantos solo utilizados en circunstancias limitadas a fin de avanzar una actividad
sucesora con respecto a la predecesora, y los retrasos son utilizados cuando los procesos
requieren un cierto período de tiempo entre las predecesoras y lo sucesoras sin trabajo
o impacto en los recursos.
Permiten ajustar el cronograma si se produce algún imprevisto o se detecta algún
fallo en la planificación.
Compresión del Cronograma (Schedule compression)

Durante la planificación el cliente puede solicitar una fecha de finalización que no
puede cumplirse o, en fase de ejecución, puede producirse un riesgo imprevisto o un
retraso sistemático de finalización de las actividades. En estos casos, el project manager
debe tratar en primer lugar (y, por supuesto, antes de informar al cliente a quien hay
que convocar cuando haya un diagnóstico claro y diferentes soluciones evaluadas con
sus impactos en las restricciones del proyecto) cómo puede acortar los plazos o recuperar
los tiempos perdidos.
Las dos principales técnicas para comprimir el cronograma son la intensificación
(crashing) y la aceleración o ejecución rápida (fast-tracking), cada una de las cuales tiene
sus ventajas y desventajas. En ambos casos, se pretende reducir plazos sin reducir el
alcance del proyecto ni reducir los requerimientos del producto.
Intensificación (Crashing)
Es una técnica que consiste en añadir más recursos a las tareas del camino crítico
para así absorber los retrasos acumulados. Ello conlleva aumentar el coste de la tarea y
del proyecto en general. Si no hay recursos disponibles, es una opción a descartar. La
intensificación solo funcionará con aquellas actividades que forman parte del camino
crítico, por lo que además tendremos la dificultad de que al acortar ciertas tareas el
camino crítico puede cambiar a otras actividades sobre las que no estamos aplicando
intensificación, por lo que además de incrementar coste, no estaríamos obteniendo la
reducción esperada de plazo.
Por ejemplo, si tenemos que revisar varios capítulos de una novela y la edición puede
no estar lista para la Feria del Libro, hito considerado innegociable, se deberán contratar
correctores adicionales que aumentarán el coste de la actividad de corrección.
Ejecución rápida (Fast-tracking)

Es una técnica que consiste en realizar paralelamente o con un cierto adelanto, dos
tareas del camino crítico que estaban previstas que se realizaran secuencialmente. Esta
acción implica riesgos ya que luego puede haber costes por tener que rehacer tareas mal
ejecutadas.
En el caso que veníamos poniendo sobre la redacción de un libro, podemos decidir,
ya que no podemos contratar correctores adicionales que la corrección se hará parale-
lamente a su escritura, corrigiendo sobre una de las últimas versiones enviadas por el
escritor. En este caso se adelanta plazo, pero los riesgos de mala calidad y de costes de
corrección pueden ser muy altos.
Otras Opciones de compresión

El project manager puede reevaluar los riesgos y tratar, mediante acciones concretas
–recogida de más información, evaluación más detallada del trabajo previsto…–, de
reducir su probabilidad o su impacto. Al reducir el riesgo, se reducirá la incertidumbre
en las estimaciones de tiempo, se podrá reducir la contingencia de tiempo prevista ini-
cialmente y se reducirá el tiempo total estimado para la tarea.
Si ninguna de las opciones anteriores, cuya condición era no reducir el alcance del
proyecto ni la calidad del producto, son posibles, cabrán dos opciones menos reco-
mendadas:
• Reducir el alcance (Reduce scope)

En caso de que no existan otras posibilidades, el project manager puede negociar
con el cliente la posibilidad de sacar del proyecto elementos que, sin ser vitales,
puedan entregarse en una segunda fase (el manual de un programa, por ejemplo).
Reducirá el plazo, pero impactará negativamente en nuestra imagen ante el
cliente.
• Reducir la calidad (Reduce quality)
Es otra opción absolutamente nada aconsejable, ya que aumentará los riesgos
pudiendo provocar retrasos superiores a los logrados al reducir las actividades de
control de calidad, además de ser poco profesional y dejar una mala imagen ante
el cliente.
Sistema de información para la Dirección del Proyecto (Project Management

Information System- PMIS)
Los sistemas de información para la dirección del proyecto suelen incluir software de
programación, que permiten el proceso de construir un modelo de cronograma obte-
niendo las fechas de inicio y final de las actividades a partir de la introducción de las
actividades, diagramas de red, recursos, y las duraciones de las actividades. Sobre este
modelo podremos probar diferentes escenarios y ver cómo afectan al camino crítico y
al plazo final del proyecto de forma automática.
Planificación ágil de versiones (Agile release planning)

La planificación ágil de versiones proporciona un cronograma resumido de alto nivel
del calendario de versiones (releases). También determina el número de iteraciones
(sprints) en cada versión y permite al equipo determinar las necesidades de desarrollo y
cuánto tiempo llevará tener un producto entregable a la vista de los objetivos de negocio,
dependencias e impedimentos.
Puesto que las características/funcionalidades representan valor al cliente, este cro-

nograma resumido de alto nivel representa una forma más fácil de entender el calendario
de proyecto, y cuando estará disponible cada característica.
SALIDAS (OUTPUTS):
Como resultado de este proceso obtendremos en primer lugar la línea de base del
cronograma, versión aprobada del cronograma que únicamente podrá ser modificada
mediante el proceso formal de control integrado de cambios. Debe ser aceptada y apro-
bada por el equipo de gestión del proyecto y por las partes interesadas más relevantes.
La última versión aprobada se tomará como referencia para la comparación entre el
avance real y el planificado. Esta información servirá de entrada para procesos como el
de estimar costes, elaborar el presupuesto o planificar las adquisiciones del proyecto.
Se obtendrán también los datos del cronograma utilizados para elaborarlo que habrá
que tener en cuenta en la fase de ejecución, seguimiento y control del proyecto –hitos
del cronograma, actividades y sus atributos, documentación que recoja las restricciones
y suposiciones, necesidad temporal de recursos, cronogramas alternativos-, así como los
calendarios de proyecto necesarios para procesos posteriores. Por último, en este pro-
ceso, se realizarán las solicitudes de cambio necesarias tras obtener los resultados antes
indicados, y las actualizaciones que sean procedentes tanto al Plan de Dirección de
Proyecto como a los documentos de proyecto.
Línea base del Cronograma (Schedule baseline)

La línea base del cronograma es la versión aprobada del modelo del cronograma que
sólo puede ser modificada mediante el procedimiento de control de cambios y se utiliza
como base para la comparación con los resultados reales en cada momento el proyecto.
Se puede generar diferentes líneas de base a lo largo del proyecto que actualicen la inicial
siempre que el equipo y las partes interesadas la aprueben y acepten la nueva línea de
base.
Cronograma del proyecto (Project schedule)

El cronograma de proyecto es una salida del modelo de cronograma que presenta
las actividades relacionadas con las fechas planificadas, duraciones, hitos y recursos.
Como mínimo, el cronograma de proyecto debe incluir la fecha planificada de inicio
la fecha planificada de final para cada una de las actividades. Si la planificación de recursos
se ha realizado en una fase temprana, el cronograma de proyecto permanecerá en estado
preliminar hasta que la asignación recursos haya sido confirmada y las fechas de inicio
y final haya sido establecidas.
El resultado final será un cronograma que todo el equipo y partes interesadas deberán
conocer y, si hemos tomado todas las precauciones aprendidas hasta el momento, debié-
ramos tener una estimación bastante razonable del avance previsto del proyecto, de las
fechas de cumplimiento de los hitos relevantes y del plazo final.
Este cronograma puede presentarse como:

• Un diagrama de barras (bar chart) como el de la figura anterior muestra:
– Cuándo empieza la tarea.
– Cuándo acaba.
– Quién debe hacerla, ya que incluye los recursos asignados.
• Un diagrama de hitos (milestones diagram).
• Un diagrama de red (network diagram).
Con los programas de Dirección de Proyectos habituales, es inmediato el cambio

de un tipo de representación a otra.
Datos del Cronograma (Schedule data)

Es información de soporte que permita complementar los resultados gráficos del
cronograma. Por ejemplo, los requisitos, criterios y asignaciones finales de recursos, el
uso de recursos en el tiempo, posibles cronogramas alternativos que se tengan previstos
como respuesta, por ejemplo, a un riesgo previsto, o la planificación de reservas para
contingencias…
Calendarios de proyecto (Project calendars)

Estos calendarios darán información sobre los días laborables que habrá que tener
en cuenta durante la ejecución del proyecto. Estos calendarios distinguen el período de
tiempo en días que están disponibles para completar actividades programadas de periodos
de tiempo que no están disponibles para trabajar. Un modelo de cronograma puede
Planificar la gestión de costes del proyecto 275
requerir más de un calendario del proyecto a fin de permitir diferentes periodos de

trabajo para ciertas actividades. Los calendarios del proyecto voy a ser actualizados.
Actualizaciones al Plan de Dirección del Proyecto (Project Management Plan

Updates)
Como resultado de la elaboración del cronograma puede ser necesario actualizar,
entre otros, y el Plan de Gestión del Cronograma –para reflejar la forma en que será
desarrollado y gestionado– así como alguna de las líneas de base del cronograma (cro-
nograma, coste y/o alcance).

Durante la realización del cronograma será necesario, fruto de los cambios, nuevos
datos obtenidos, problemas encontrados…, cambiar algunos de los documentos ya ela-
borados:
• Atributos de actividad
• Registro de asunciones
• Estimación duraciones
• Requisitos de recursos
• Registro de riesgos
• Estimación de duraciones
• Registro de lecciones aprendidas
Así, toda la documentación será coherente y reflejará la realidad actualizada del
proyecto.
Al elaborar el programa y analizarlo el project manager se da cuenta de que,
siguiendo ejemplos ya utilizados, necesitará más correctores de texto o un segundo
equipo de montaje de turbinas… y deberá actualizar los documentos donde se especi-
fican los recursos asignados y actualizar, por ejemplo, el registro de riesgos derivados de
estos nuevos recursos o equipos, pero todo ello con antelación.
3.7. PLANIFICAR LA GESTIÓN DE COSTES DEL PROYECTO
Buena parte de los proyectos tienen como objetivo final obtener un beneficio ya
económico, en el caso de las empresas, ya social, en caso de las organizaciones. Y en
ambos casos tener claros y bien estimados los costes nos ayudará a:
• Tener una buena estimación de la rentabilidad esperada.
• Comparar los beneficios esperados con los costes previstos.
• Valorar la conveniencia de iniciar el proyecto.
• Acotar la inversión y financiación necesaria.
El presupuesto de un proyecto es una estimación detallada y distribuida en el tiempo
del coste de los recursos necesarios para llevarlo a cabo.
En el anterior capítulo hemos visto como se identificaban las actividades como uni-
dades más pequeñas que el paquete de trabajo. Estas actividades se utilizan para crear los
presupuestos a partir del coste de cada actividad. En ocasiones los costes pueden calcu-
larse a un nivel más agregado, a nivel de cuentas de control, como nivel superior a los
paquetes de trabajo de la EDT.
Costes a tener en cuenta

Los costes que habrá que considerar serán no sólo los correspondientes a recursos
humanos (project manager y todo el equipo) sino también la contratación de servicios
externos, las adquisiciones de bienes y equipos, los controles de calidad, los resultantes
de los planes de respuesta a los riesgos, los costes de materiales asociados al proyecto, los
gastos de oficina, los gastos generales…
Dependiendo de los proyectos, el coste de operación y mantenimiento (operation
and maintenance costs) de la infraestructura puede ser muy alto. En estos casos se deberá
incluir en las decisiones del diseño y proyecto a abordar. Podría darse el caso de que se
logren ahorros en el diseño y construcción de una determinada infraestructura pero que
los costes en la fase de operación y mantenimiento sean muy superiores. Pueden tener
un coste de inversión bajo, pero un coste de operación y mantenimiento alto, y vice-
versa, y teniendo ambas alternativas, se deberá evaluar sus VAN, TIR..., para ver si los
ahorros en primera instancia son mayores o menores que los sobrecostes durante la vida
útil de la infraestructura.
Al coste que incluye los costes de proyecto, desarrollo, ejecución, operación y
mantenimiento y operación le llamamos Coste del ciclo de vida del producto.
Tipos de costes
Los costes del proyecto tienen un componente:
• Directo, directamente atribuible al proyecto: mano de obra –interna y subcon-
tratada–, materiales y equipamiento, otros costes directos –tarifas, viajes…–.

• Indirecto, correspondiente a la organización y no directamente atribuibles al
proyecto: administración general, gastos corporativos, electricidad... Estos a su
vez se pueden categorizar en:
– Gastos generales: alquileres de las oficinas…
– Gastos generales y administrativos, que permiten a la organización operar:
costes del departamento financiero y de la alta dirección, servicios jurídi-
cos…
Asimismo, pueden también ser:
• Variables, si dependen de la producción o de la cantidad de trabajo realizado:
papel, gasolina de los vehículos, gastos de viajes y dietas…
• Fijos e independientes de la cantidad de trabajo realizado, como el alquiler del
edificio.
Momento de consideración del coste

Cómo y cuándo se considerarán los costes del proyecto influirá en el diseño de
captación de datos de costes para evaluar el desempeño de costes (y en el plan financiero
para hacer frente al cash-flow del proyecto). El momento de consideración del coste
estará condicionado, a su vez, por el sistema de contabilidad de la empresa. Diferentes
momentos de consideración de los costes pueden dar diferentes resultados de los pará-
metros de desempeño.
No será igual si el coste de la adquisición de una turbina se mide cuando:
• se toma la decisión de compra,
• se hace el compromiso de compra,
• se formaliza el pedido,
• se entrega en destino,
• se incurre en el coste real (pago), o
• éste se registra a fines de contabilidad imputada al proyecto.
Niveles de detalle y precisión del presupuesto

Los costes se estiman con diferente grado de detalle en función del nivel de precisión
requerido en cada fase y, sobre todo, del nivel de información disponible:
• información básica en los estudios de viabilidad o de selección de proyectos,
• cuando los objetivos y el alcance están definidos y existe información razonable
de recursos, materiales…, o
• cuando existe información detallada a nivel de paquetes de trabajo y actividades.
La estimación menos precisa será la que utilice órdenes de magnitud y ratios basados
en proyectos similares o ratios de coste y productividad estándar en la empresa o en el
sector. Por el contrario, el análisis de costes más preciso será el que se realice partiendo
de las actividades en que se han desglosado los paquetes de trabajo de la EDT.
Project Management Institute, A Guide to the Project Management Body of

Knowledge (PMBOK®Guide) – Sixth Edition, Project Management Institute, Inc.,
2017 define tres niveles de estimación que son:
• El ROM (Rough Order of Magnitude), que sería el nivel menos preciso y que
variará entre un –25% y +75% respecto al real aunque dependerá del conoci-
miento del proyecto y de las diferencias respecto a otros proyectos similares.
• La estimación del presupuesto, que se realiza durante la fase de planificación y
que puede variar respecto al presupuesto real entre un –10% y un +25%.
• La estimación definitiva, que se irá afinando conforme avance el proyecto y se
ejecute una parte relevante del mismo que se ajustará al rango de +10%, –5%.
Mostramos por su interés y su carácter intuitivo el cono de incertidumbre de
McConnell muy utilizado en proyectos de desarrollos informáticos cuyos valores sin ser
iguales son similares a los anteriores:
Procesos del área de conocimiento de gestión de costes

En el esquema siguiente, vemos los tres procesos del grupo de procesos asociados a
la gestión de costes del proyecto, dos de ellos desarrollados en la fase de planificación y
un tercero en la de supervisión y control (en el que se resaltan las iteraciones posibles
en la fase de planificación y ejecución, supervisión y control):
del PMBOK y la ISO21500 en lo que a gestión de costes se refiere. En el siguiente cuadro
se reflejan los procesos de PMBOK y los de ISO21500 (estos últimos en cursiva):

Plan de Gestión de Costes Controlar los costes
Estimar los costes (Controlar los costes)
Determinar el presupuesto
(Estimar los costes)
(Elaborar el presupuesto)
En la tabla siguiente se describen brevemente:
Este proceso tiene por objetivo establecer las políticas, procedimientos y

documentación necesaria para planificar, gestionar, ejecutar, controlar y
Planificar la gestión reportar los costes de los proyectos para asegurar que los datos, procesos,
de costes técnicas y herramientas y resultados entre proyectos son coherentes y
(Plan cost manage- comparables.
ment)
No existe este proceso en ISO21500 aunque se considera que se elabora como
parte del Plan de Dirección del Proyecto y sus Planes Subsidiarios.
Para abordar este proceso el project manager debe conocer bien el trabajo
que va a tener que realizar y cuánto tiempo le va a llevar hacerlo. Trata
de estimar con la máxima exactitud cuánto va a costar realizar cada acti-
Estimar los costes vidad. Por ello, para cada actividad se estiman las horas necesarias por
(Estimate costs) tipo de personal, los costes de materiales necesarios, posibles compras a
proveedores o servicios de consultoría.
No existen diferencias entre ISO21500 y PMBOK 6.ª Edición en lo relativo a

este proceso.
En este proceso se van agregando los costes de cada actividad para estimar
los de cada paquete de trabajo, cuentas de control definidas y, así suce-
sivamente, hasta llegar a los del proyecto completo. Con todo ello, se
Determinar el pre- prepara una línea base del desempeño de costes de ejecución del pro-
supuesto yecto. El project manager comparará los costes realmente incurridos con
(Develop budget) esta línea base.

este proceso.
Durante la ejecución del proyecto el project manager se encarga de
supervisar el trabajo realmente completado, las horas realmente dedicadas
a cada actividad, los materiales realmente comprados, el precio final real
de las compras de servicios o equipamientos. Estos costes los compara
Controlar los costes con los previstos y realiza, si procede, los cambios en la línea de base que
(Control costs) sean aprobados mediante el procedimiento integrado de gestión de cam-
bios establecido.

este proceso.
Tendencias y prácticas emergentes de Gestión de Costes en Proyectos

Con respecto uso de la práctica a la Gestión del Coste del proyecto, la tendencia es
incluir la expansión de la gestión del valor ganado (EVM) para incluir el concepto de
Programación ganada (Earned Schedule – ES)
Programación ganada (ES) es una extensión a la teoría y práctica del valor ganado.
Calendario ganado sustituye las mediciones de variación del calendario en el método
tradicional (Earned Value – Planned Value) del valor ganado con ES (Earned Schedule)
y AT (Actual time).
De igual forma, se modifican los índices de desempeño, proyecciones, etc… En esta
área de conocimiento se analizan en profundidad el método del valor ganado, y la idea

principal es que, con esta extensión, el método se aplicaría de forma análoga pero sus-
tituyendo ES en vez de EV, y AT en vez de PV.
Consideraciones de adaptación a la gestión. (Tailoring considerations)

Puesto que cada proyecto es único el Project manager puede necesitar adaptar la
forma en que los procesos de gestión de costes serán aplicados. Algunas consideraciones
de consideración a tener en cuenta son:
• Gestión del conocimiento: ¿Dispone la organización de un repositorio de
gestión del conocimiento e información financiera, que el project manager
puede utilizar y a los que acceder con facilidad?
• Estimaciones y presupuestos: ¿Dispone la organización de instrucciones,
procedimientos y políticas relativos a la estimación y presupuesto de costes?
• Gestión de valor ganado: ¿Utiliza la organización la gestión del valor ganado
en la gestión de proyectos?
• Enfoque ágil de proyectos: ¿Utiliza la organización metodologías ágiles en

la gestión de proyectos? ¿Cómo impacta en la estimación de costes?
• Gobernanza: ¿Dispone la organización de políticas, procedimientos, o guías
de auditorías y gobernanza
Consideraciones para entornos ágiles. (Considerations for Agile/Adaptive

environments)
En proyectos con alto grado de incertidumbre, no tiene demasiado sentido realizar
cálculos de coste muy detallados, debido a los frecuentes cambios. En vez de esto, la
utilización de métodos estimación más ligeros pueden ser utilizada para generar previ-
siones rápidas y alto nivel del coste de los trabajos a realizar, que podrán ser fácilmente
ajustadas cuando lleguen los cambios. Las estimaciones de detalle se reservarán para
planificaciones a muy corto plazo.
En casos en que tenemos proyectos con una alta variabilidad y con presupuestos
muy ajustados, será necesario ajustar alcance y plazo con bastante frecuencia, para man-
tener las restricciones del presupuesto
3.7.1. Planificar la gestión de costes

El Plan de Gestión de Costes tiene como objetivo definir cómo se van a planificar,
monitorizar y controlar los costes del proyecto y gestionar las posibles desviaciones
(ahorros o sobrecostes).
Por lo tanto, lo primero que el project manager debe abordar es la elaboración del
Plan de Gestión de Costes del proyecto que contendrá:
• El nivel de exactitud –función del alcance de las actividades y la magnitud del
proyecto– y de detalle.
• El tipo de costes que se incluirán (directos, indirectos, los del ciclo de vida del
producto…).
• Las unidades de medida que se utilizan en las mediciones.
• La línea de base del presupuesto con la que comparar el avance real durante la
ejecución.
• Las medidas de desempeño, indicadores de rendimiento para detectar las des-
viaciones.
• Umbrales de control a partir de los que activar las respuestas a la variación de
los costes.
• El procedimiento para gestionar las desviaciones del coste respecto a la línea
base.
• Los procedimientos de control de cambios en el presupuesto.
• Formatos y descripciones de los procesos.
En definitiva informará sobre cómo se deben desarrollar los siguientes procesos:
Estimar los costes (estimate costs), Determinar el presupuesto (determine budget) y
Controlar los costes (control costs).
En la práctica interactúan entre sí y se superponen. En proyectos pequeños, la esti-

mación de costes y la preparación del presupuesto suelen considerarse un único proceso.
En cualquier caso, la definición temprana de cuál es el verdadero alcance, qué está
incluido y qué no, es crítica para tener una estimación lo más precisa y exacta de los
costes del proyecto.
En este esquema se ubica el proceso de estimación de Planificar la gestión de costes
(Plan cost management) dentro del área de conocimiento de costes y el grupo de pro-
cesos de planificación:
En este esquema se presenta el proceso particular de estimar los costes de cada acti-
vidad con sus entradas, técnicas y herramientas y salidas:
En ISO21500 no existe el proceso de planificar la gestión de costes ya que se considera

dentro del proceso de «Desarrollar los planes de proyecto (Develop Project plans)».
PLAN DE GESTIÓN DE COSTES (PLAN COST MANAGEMENT):

Este proceso establece las políticas, procedimientos y documentación necesaria
para planificar, gestionar, ejecutar, controlar y reportar los costes de los proyectos.
El beneficio clave de este proceso es que proporciona guía y dirección sobre cómo
se gestionarán los costes a lo largo del proyecto.
ENTRADAS (INPUTS):
Entre la información necesaria para elaborar el plan de gestión de costes están: el

plan de dirección de proyecto –dentro del cual están el acta de constitución –donde
habrá un presupuesto global estimado o acordado-, la línea de base del alcance – el
alcance y la EDT- y la línea de base del cronograma –que define cuándo se incurrirá en
los costes-, los factores ambientales de la empresa como la cultura, estructura y procesos
que pueden afectar a la gestión de costes y, por último, los activos de procesos de la
organización como son los procedimientos de control financiero, la información his-
tórica de proyectos anteriores o procesos específicos de gestión de costes establecidos
en la organización.

En el Acta de Constitución se encontrarán requisitos y restricciones de alto nivel
algunas de ellas asociadas a los objetivos de coste del proyecto, los límites presupuestarios
o los condicionantes de financiación, entre otros.


El Plan de Gestión del Cronograma, definirá entre otras cosas, los criterios y las
actividades para desarrollar, monitorizar, Y controlar el cronograma. Plan de gestión de
programa proporciona procesos y controles te impactarán en la estimación y gestión de
los costes.
Plan de Gestión de Riegos (Risk management plan)

El Plan de Gestión de Riesgos proporciona el enfoque para identificar, analizar, y
monitorizar riesgos. Además, proporciona procesos y controles te impactarán en la esti-
mación y gestión de los costes.
Factores ambientales de la organización (Enterprise environmental factors)

Entre los factores ambientales que condicionarán la elaboración del Plan de Gestión
de Costes estarán, por una parte, la cultura y estructura organizativa de la organización
y, por otro lado, las condiciones de mercado que habrá que tener en cuenta a la hora
de elaborar el presupuesto. Otras fuentes de información pueden ser los datos históricos
de costes y los sistemas de gestión de la información de proyectos que posea la compañía.
Las tasas del cambio de moneda cuando trabajamos con más de un país, los distintos
sistemas de gestión de la información del proyecto, las diferencias entre la productividad
en diferentes partes del mundo que puede tener una influencia considerable en el coste
del proyecto, son otros de los factores a tener en cuenta.
Activos de los procesos de la organización (Organizational Process assets)

Los procesos de elaboración y aprobación de presupuestos, los costes internos de la
compañía, las políticas de costes en la compañía…, afectarán a cómo se planifique la
gestión de costes del proyecto.
El project manager utilizará el juicio experto y se apoyará en información histórica

de costes reales de proyectos o partes de proyectos similares para estimar costes o elaborar
presupuestos y, para lograr un resultado realista, consensuado y con el compromiso de
las partes implicadas, se reunirá con el sponsor del proyecto, los miembros del equipo
procedentes de departamentos implicados, partes interesadas relevantes y aquellas per-
sonas con responsabilidades en la planificación o ejecución del presupuesto.

El apoyo en las aportaciones de personal experimentado en proyectos similares
anteriores, información histórica, estimación de costes y presupuestos o Gestión del
Valor ganado, que ayudarán a recoger las mejores prácticas en gestión de costes del
proyecto.

Al elaborar el Plan de Gestión de Costes puede ser necesario buscar nuevas formas
de financiación y evaluar qué modelo de financiación (auto financiación, mediante
deuda, mediante equity, …) es el más adecuado a las necesidades del proyecto. También,
por ejemplo, si para ciertos recursos vamos a considerar su ejecución por el equipo
(hacer), o bien adquirir, leasing, renting, etc… El Plan de Gestión definirá, por tanto,
cómo se va a financiar los recursos necesarios para el proyecto y sus implicaciones en la
gestión y control de costes.
El project manager y su equipo podrán mantener reuniones con las diferentes partes
interesadas que tengan o deban estar más implicadas en la planificación, gestión, control
y toma de decisiones relativas a los costes del proyecto.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtendrá el Plan de Gestión de Costes que debe
describir cómo se planificarán, estructurarán, monitorizarán y controlarán los costes del
proyecto.
Plan de Gestión de Costes (Cost management plan)

Entre los elementos que pueden incluir este plan estarán:
• La unidad de medida en la que se va a medir (horas, días, toneladas…).
• Nivel de precisión: es el grado al que se redondearán las estimaciones de costes
teniendo en cuenta las actividades y la magnitud del proyecto (a miles de dólares,
euros…
• Nivel de exactitud: es el rango aceptable de variación de las estimaciones
(+10%).
• Enlaces a los procedimientos de la organización relacionados con la gestión de
costes como son, por ejemplo, las cuentas de control, nivel de la EDT al que se
recogerán y evaluará el desempeño de costes.
• Los límites de control –variación en el coste que activará la toma de decisiones–
y el escalado de las decisiones al respecto.
• La organización de la recogida, control y reporte de la información –actividades,
paquetes de trabajo, cuentas de control...–.
• Las reglas para medir el desempeño en costes –definición de cuentas de control,
técnica de medición del Valor Ganado, cómo estimar el presupuesto final actua-
lizado...–.
• Los formatos de reporte y su frecuencia.
• Otros aspectos como el procedimiento para registrar un coste y los roles y res-
ponsabilidades en la gestión de costes.
Este Plan de Gestión de Costes se utilizará cómo entrada para:

– Los procesos de estimar costes y determinar el presupuesto.
– Así como para los de identificar los riesgos –cómo se incorporan las reservas de
costes de contingencia y gestión– y análisis cualitativo de los riesgos –en el que
se utiliza el impacto de un riesgo en el presupuesto para su evaluación–.
3.7.2. Estimar los costes

En este proceso se calculan con la mayor precisión posible los recursos económicos
necesarios para completar las actividades del proyecto basándose en la información dis-
ponible en un momento dado y que deberá afinarse en el curso del proyecto para tratar
de tener el presupuesto actualizado más realista posible. El Plan de Gestión de Costes
del proyecto debe haber establecido cómo se va a proceder a la estimación de costes en
las diferentes fases del proyecto –inicio/oferta, planificación del proyecto/elaboración

de presupuesto– y con qué datos de partida.
Los costes de una actividad incluirán los correspondientes a personal, materiales,
equipamiento, servicios, instalaciones, así como otras categorías especiales como los
costes de contingencia (asociados a riesgos identificados y aceptados).
A la hora de realizar la estimación de los costes conviene tener en cuenta algunos
aspectos o buenas prácticas que, por repetidas, no siempre se tienen en cuenta. Las
estimaciones serán más detalladas conforme mejor y más completa sea la estructura de
desglose de trabajo que permitirá una descomposición en actividades más acotadas. Para
ello se tratará de obtener una descomposición en actividades más acotadas, claras y pre-
cisas. Asimismo, conviene que las estimaciones las haga quien realmente hace o va a
hacer el trabajo para completar la actividad apoyándose en la experiencia y el conoci-
miento adquirido por la empresa en proyectos anteriores.
Una vez completa la estimación se guardará la línea de base de costes, que no deberá
ser modificada salvo tramitación expresa mediante el sistema integrado de control de
cambios y aprobación por el comité de control de cambios.
En ocasiones, el cliente o el patrocinador imponen un coste máximo al proyecto.
El project manager debe tener la capacidad profesional para estudiar detalladamente el
proyecto y si el coste es superior, presentarlo razonadamente y buscar puntos de encuen-
tro. Asimismo, tiene la obligación ética de estimar y mantener unos costes reales durante
todo el proyecto sin ningún tipo de manipulación.
Como se ha indicado anteriormente, los costes a estimar no son únicamente:
• Los relativos a las horas*persona de elaborar las actividades que conforman el
trabajo.
• Y los costes de adquisición de equipamientos y/o servicios.
Sino que los costes a estimar son también los relacionados con:
• Los costes de gestión del proyecto (tiempo dedicado por el project manager, el
patrocinador, los jefes funcionales en reuniones de negociación, coordinación,

planificación…).
• El aseguramiento y control de la calidad.
• Los relativos a los planes de respuesta a riesgos (reservas de contingencia).
• Los costes de formación y capacitación del personal.
• Los costes de papelería, viajes, hoteles, dietas…
• Los gastos generales, no directamente imputables al proyecto concreto, como
son los gastos de dirección y administración.
A estos, la dirección añadirá el beneficio industrial, si procede.
En este esquema se ubica el proceso de estimación de costes (estimate costs) dentro
de la gestión de costes y las fases del proyecto:
En este esquema se presenta el proceso particular de estimar los costes de cada acti-
vidad con sus entradas, técnicas y herramientas y salidas:
En ISO21500 existe este mismo proceso con objetivos y resultados similares. También en
ISO21500 tiene por objetivo obtener una aproximación de los costes necesarios para completar
cada actividad de proyecto y, por ende, los paquetes de trabajo y el proyecto global.
Cuando los proyectos tienen una larga duración puede ser necesario trabajar con moneda
constante aplicando las tasas de descuento correspondiente e incluyendo una cláusula de revisión
de precios en el contrato.
Las estimaciones de reservas de contingencia se utilizan para abordar riesgos previstos y
planificados, deben ser añadidas a la línea de base del coste y estar claramente identificadas.
Entradas Salidas
Lista de actividades Estimaciones de costes
Planes de proyecto
Cambios aprobados
ESTIMAR LOS COSTES (ESTIMATE COSTS):

En este proceso se calcula una aproximación al coste de los recursos necesarios
para completar el trabajo de proyecto, basándose en la información disponible en un
momento dado y que deberá afinarse en el curso del proyecto para tratar de tener el
presupuesto actualizado más realista posible.
El beneficio clave de este proceso es que determina los recursos necesarios reque-
ridos para el proyecto.
ENTRADAS (INPUTS):
Para estimar los costes utilizaremos el plan de dirección de proyecto, en particular

plan de gestión de costes –que define cómo se van a definir y estimar los costes (método,
datos de partida, precisión,), el plan de gestión de calidad –en el que se indican los
objetivos de calidad a cumplir–, y la línea de base del alcance –que nos define el alcance
de los trabajos a realizar y ayudará a estimar correctamente los costes–. También se
utilizarán algunos documentos del proyecto, como por ejemplo: el cronograma del
proyecto –nos indica cuándo se realizará cada actividad y permite calendarizar los cos-
tes-, el registro de riesgos –donde aparecerán los planes de respuesta asociados a las
actividades o paquetes de trabajo-, los factores ambientales de la organización –condi-
ciones del mercado, muy especialmente– y, por último, los activos de los procesos de
la organización –procedimientos de estimación, bases de datos de costes, plantillas, lec-

ciones aprendidas en lo que a estimación de costes se refiere,…–.

Plan de Gestión de Costes (Cost management plan)

Es el documento que nos indica, entre otras cosas, los métodos con los que se van
a estimar los costes, así como el nivel de precisión y exactitud.
Plan de Gestión de Calidad (Quality management plan)
El plan de gestión de calidad describe las actividades y recursos necesarios para que
el equipo de gestión de proyecto consiga los objetivos de calidad establecidos para el
proyecto.

Nos informa sobre el detalle de las actividades a estimar, el alcance y las restricciones
que tiene el proyecto y, en ella, encontraremos los tres documentos que la componen:
• El Enunciado del Alcance del trabajo: refleja restricciones a la financiación por
cada período de gastos del proyecto, u otras restricciones o asunciones finan-
cieras.
• La EDT relaciona el trabajo del proyecto con todos los entregables e informa,
por tanto, del trabajo cuyo coste tenemos que estimar.
• El diccionario de la EDT, descripción detallada del paquete de trabajo y su
alcance, que ayudará a mejor estimar los costes de cada paquete de trabajo.

Muestra la duración general del proyecto y cómo se distribuyen en ese período las
actividades. Contiene las actividades, tipo y cantidad de recursos necesarios para su rea-
lización y las fechas previstas de inicio y fin. Las estimaciones de duración afectarán a
las estimaciones de coste cuando los recursos son cargados por unidad de tiempo y
cuando hay fluctuaciones estacionales en los costes.
Las fechas también pueden afectar a los costes de diferentes maneras: una compra
anticipada puede permitir conseguir mejores precios; por otra parte, los gastos finan-
cieros variarán con el cashflow del proyecto.
Requisitos de recursos (Resource requirements)

Es un elemento importante ya que es una lista descriptiva de los recursos que se
necesitan para realizar cada actividad y paquete de trabajo. En ella se indican los recursos
asignados a cada actividad, así como la disponibilidad de los mismos.
Registro de riesgos (Risk register)

El registro de riesgos contiene detalles de los riesgos del proyecto que han sido
identificados y priorizados, así como los planes de respuesta al riesgo, que se han esta-
blecido.
Como se ha indicado al presentar el esquema general de planificación y las activi-
dades a realizar, la planificación es un proceso iterativo cuyo alcance, coste y duración
no pueden cerrarse hasta conocer los resultados del Plan de Calidad y el de Riesgos.
Si el project manager conoce los riesgos que pueden afectar al proyecto le ayudarán
a conocer el coste de evitarlos o aceptarlos. El coste de las acciones correctivas o pre-
ventivas de respuesta a eventos de riesgo previsibles y con alto impacto debe recogerse
en el presupuesto.
Por tanto, habrá unos costes asociados a los riesgos. Pero a su vez, los costes de los
riesgos pueden ser también un riesgo –si se incrementan excesivamente–. Por lo tanto,
es un proceso iterativo donde los riesgos son una entrada del proceso de estimación de
costes (estimate costs) y una salida del mismo.
El equipo de proyecto también debe estar atento a las oportunidades que surjan y
que pueden permitir reducir costes o reducir los plazos (reduciendo así costes).
Registro de Lecciones aprendidas (Lesson learned register)

Lecciones aprendidas al inicio de proyecto, pueden ser útiles a la hora de estimar
esfuerzos o duraciones para aplicarlas a fases posteriores del proyecto, y así mejorar la
exactitud y previsión de dichas estimaciones.

Los factores ambientales de la empresa, a la hora de estimar los costes, pueden ser la
situación del mercado de productos y servicios necesarios, los proveedores existentes y
los términos y condiciones que los rigen, el posicionamiento de la organización en el
mercado, los gastos generales y márgenes habituales… así como los factores que puedan
afectar derivados del origen de los proveedores. Para proyectos que se extienden durante
varios años con distintas monedas, la fluctuación de las monedas, así como la inflación,
pueden ser elementos necesarios a introducir en el proceso de estimación de los costes.
Se tendrán en cuenta los ratios de coste de los recursos disponibles provenientes de
bases comerciales del sector.

Para estimar bien los costes, el project manager deberá tener en cuenta la informa-
ción histórica sobre estimaciones de costes, lecciones aprendidas, procedimientos de
trabajo, flujos de información y niveles de decisión, instrucciones de trabajo y plantillas,
métodos y programas de estimación de costes…
El project manager en colaboración con el equipo de proyecto y otras partes intere-

sadas elegirá, dependiendo del momento del proyecto que se trate y la información
disponible entre las distintas técnicas de estimación: estimación análoga –estimación
utilizando el presupuesto de un proyecto o parte de un proyecto similar–, una estimación
paramétrica –estimación basada en ratios de rendimiento procedentes de proyectos o
partes de proyectos anteriores– o una estimación ascendente –partiendo de los costes de
cada actividad para agregándolos obtener los de los paquetes de trabajo, entregables y
cuentas de control.
La estimación de cada actividad puede expresarse con un valor puntual o realizarse
mediante la estimación por tres puntos que utiliza tres valores –el más probable, el más
pesimista y el más optimista– para, posteriormente calcular la media, la desviación típica
y poder así dar no solo un valor medio sino intervalos de confianza entre los que pueda
encontrarse el coste real.
Otros aspectos a tener en cuenta a la hora de estimar el coste de cada actividad o

paquete de trabajo, los pondremos de manifiesto analizando los datos disponibles como,
por ejemplo: analizar los costes de calidad, las reservas de contingencia, o las distintas
alternativas a la hora de ver distintas formas de distintas opciones para realizar el trabajo.
Con respecto a las reservas de contingencia –coste del plan de contingencia o del
impacto económico de un riesgo aceptado–, conforme avanza el proyecto las reservas
de contingencia podrán utilizarse, reducirse o eliminarse. La reserva de contingencia,
que forma parte de la línea de base de coste que gestiona el project manager, debe estar
claramente identificada en la documentación de los costes. También puede estimarse
una reserva de gestión, que gestiona la dirección, para riesgos imprevistos, no planifi-
cados, que se añadirá a la línea de base de coste para obtener el presupuesto total de
proyecto.

Implica consultar con expertos o grupos de ellos, para estimar los costes, analizar la
situación del mercado y el entorno económico y determinar cómo elegir o combinar
los métodos de estimación de costes.
Estimación por analogía (Analogous estimation)

Mediante esta técnica se realizan estimaciones (de plazo o coste) basándose en pro-
yectos similares y utilizando sus resultados con ciertos parámetros de corrección que
tengan que ver con la diferencia de recursos asignados, la experiencia de uno y otro
equipo…
Es una de las técnicas más sencilla, más rápida y menos exacta pero necesaria cuando
o no hay datos suficientes para detallar más las actividades o para hacer estimaciones
iniciales. Para llevarlas a cabo se requiere experiencia y una buena base de datos históricos
que permita corregir esta estimación en función de las características concretas del pro-
yecto.
Es lo opuesto a la estimación ascendente (bottom-up estimating), ya que se estima
el presupuesto de todo el proyecto y ese total se va asignando a paquetes de trabajo en
función de los porcentajes que éstos supusieron en proyectos anteriores similares.
En síntesis, tiene:
• Ventajas: la rapidez, no requerir identificar paquetes de trabajo ni actividades,
su menor coste y que permite al project manager dar un orden de magnitud y
una idea de las expectativas del presupuesto a la dirección.
• Inconvenientes: da una estimación menos precisa, con un nivel de información
y conocimiento del proyecto limitados, requiere mucha experiencia y será difícil
de aplicar en proyectos con incertidumbre alta (proyectos de I+D…).
Estimación paramétrica (Parametric estimating)

Ya vista en Área de Gestión del Cronograma, en la estimación de duraciones, es
una técnica de estimación en la que por medio de un algoritmo se calcula el coste (o
también la duración, como vimos en el área de Gestión del Cronograma) a partir de
información histórica y parámetros de proyectos.
Esta técnica es muy similar a la anterior, si bien se realiza a través de hojas de cálculo
o programas más complejos en los que se introducen relaciones estadísticas entre los
datos históricos y otras variables (Por ejemplo: ml de tubería puesta en obra) e hipótesis
de distribución de los valores del parámetro (coste, duración…).
El resultado se obtendrá multiplicando la cantidad de trabajo (metros lineales de
tubería puesta en obra contratados) por la duración (en valor medio, intervalos de con-
fianza…) del parámetro (duración, coste…).
Puede ser:
• Una estimación tan sencilla como aplicar la media y varianza de las estimaciones
de costes obtenidas en una serie de proyectos anteriores.
• O una estimación más compleja, ajustando una distribución de probabilidades
con los datos existentes o recogidos y utilizar los parámetros de esa distribución.
Puede haber distintos tipos:
• Basadas en el análisis de regresión o scatter diagrams utilizando información
histórica de muchos otros proyectos.
• Basadas en el concepto de curva de aprendizaje (learning curve): El dispositivo
número 100 de una serie costará montarlo menos tiempo y dinero por la mejora
de eficiencia.
Estimación ascendente (Bottom-up estimating)

A partir de una EDT bien definida y estructurada y con las actividades de cada
paquete de trabajo claras e identificadas, se comienza con una estimación de costes a

nivel de actividad, que se agregan a nivel de paquete de trabajo, posteriormente en
cuentas de control y, finalmente, a nivel de proyecto, con el objetivo de facilitar el
reporte y seguimiento.
El proceso de elaboración de la EDT y la estimación a partir de sus actividades llevará
más tiempo, pero tiene claras ventajas: es la forma más exacta de estimación, facilita el
compromiso del equipo que ha participado en su elaboración y, al estar desglosada por
unidades de niveles de la EDT, si luego los costes realmente incurridos se asignan a cada
actividad, permitirá elaborar una contabilidad analítica.
Como inconvenientes cabe destacar que se necesita más tiempo y es más costoso,
exige definir en detalle el alcance (EDT) y exige responsabilidad de los estimadores.
Estimación por tres valores (Three-point estimate)

Al igual que para la estimación de duraciones los tiempos, el project manager con
su experiencia, la de su equipo y la información de la empresa u obtenida de expertos
internos o externos, estimará los costes más probables, los que pueden incurrirse si todo
va mal o los que serán si todo va bien. Con ellos se calculará (si consideramos que la
variable sigue una distribución Beta):
Duración estimada = (optimista + 4*más probable +pesimista)/6
Y con una desviación típica = (pesimista – optimista)/6
Si consideramos que la variable estimada sigue una distribución de probabilidad
triangular, se hará como:
Duración esperada = (optimista + más probable + pesimista)/3
Todas las estimaciones explicadas para el caso de la duración de las actividades son
válidas para los costes (intervalos de confianza del 99%…).
Se recomienda repasar el método de estimación por 3 puntos, detallado en el área
de gestión del cronograma.

Análisis de alternativas (Alternatives Analysis)
Los análisis de alternativas se utilizan para evaluar opciones identificadas de cara a
poder elegir que opciones o enfoques elegir para ejecutar el trabajo de proyecto. Por
ejemplo: evaluar los impactos de coste, plazo, recursos y calidad de hacer frente a com-
prar un entregable.
Análisis de reserva (Reserve analysis)

Las reservas son partidas para afrontar riesgos conocidos pero inciertos o riesgos no
conocidos y que pueden aparecer. Debemos mantener esas partidas por si el evento de
riesgo y sus costes implicados ocurren.
Las reservas de contingencia son las reservas de coste asociadas a los planes de con-
tingencia o reservas realizadas por si ocurren riesgos identificados (known unknown)
que se entiende que habremos planificado su respuesta. Solamente se activarán y utili-
zarán si el evento de riesgo ocurre. Estas reservas formarán parte de la línea de base del
coste.
Las reservas de contingencia pueden ser estimadas a cualquier nivel, desde una acti-
vidad específica hasta el proyecto completo. Las reservas de contingencia pueden esta-
blecerse como un porcentaje del coste estimado, un número fijo hola mediante la apli-
cación de métodos de análisis cuantitativos.
Por otra parte, existen otro tipo de reservas que son las reservas de gestión: se refieren
a cantidades de dinero por si aparece un riesgo no previsto (unknown unknown) y no
formarán parte de la línea de base de coste, pero sí del presupuesto total del proyecto.
Conforme se vaya teniendo información más precisa del proyecto, las reservas de
contingencia pueden utilizarse, ampliarse, reducirse o eliminarse (si finalmente no se
concretó el evento de riesgo para el que se había hecho una reserva de contingencia).
Conviene documentar de forma explícita las reservas de contingencia en el presupuesto
y que no aparezcan ocultas o implícitas en otras partidas.
Coste de la calidad (Cost of Quality, COQ)

La calidad tiene un coste que la experiencia dice que es menor que el coste de la no
calidad, que incluye los de la mera corrección de errores, la pérdida de confianza del
cliente o el aumento de los riesgos del proyecto, y los retrasos en el cronograma.
En cualquier caso, se deben presupuestar y controlar todas las actividades de super-
visión y control –revisiones, ensayos, sistemas de detección…– para garantizar que el
producto cumpla los requisitos de calidad definida por el cliente.
Sistema de información para la Dirección del Proyecto (Project Management

Information System-PMIS)
Los sistemas de información para la dirección del proyecto suelen incluir hojas de
cálculo, software de simulación y herramientas de análisis estadístico, para ayudar con la
estimación de costes., que permiten el proceso de construir
Cualquier programa de estimación de costes y cálculo de presupuestos puede valer.
Éstos suelen ayudar a calcular la estimación de costes. Pueden ser tan simples como una
hoja de cálculo en la que introduces las estimaciones de costes de los recursos, los costes
laborales y materiales y calcula el cálculo total o más complejos e integrados en programas
de gestión de proyectos. Para proyectos complejos ahorrarán tiempo, ya que permiten
evaluar distintos escenarios y situaciones, y evitarán errores (siempre que la información
suministrada al programa sea correcta).
Toma de decisiones (Decision Making)

Distintas técnicas pueden ser utilizadas para tomar decisiones sobre las estimaciones,
como por ejemplo votación. Estas técnicas suelen ser útiles para involucrar miembros
del equipo a fin de mejorar la precisión y el compromiso de las estimaciones que se
realizan.
Otras técnicas como brainstorming, el método Delphi…pueden ayudar a realizar
unas buenas estimaciones contando con la participación de un grupo de personas que

tengan su propia experiencia y punto de vista.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtienen las estimaciones de coste de las activi-
dades o paquetes de trabajo y, no menos importante, la documentación de soporte a las
estimaciones –cómo se hizo la estimación, las suposiciones realizadas, las restricciones
consideradas, el intervalo y su nivel de confianza…– que permitirá identificar durante
la ejecución del proyecto las causas de las desviaciones de los costes y recoger lecciones
aprendidas para futuras estimaciones.
Estas salidas serán entradas a su vez en el proceso de identificar riesgos –las estima-
ciones se han realizado con un nivel de incertidumbre y con suposiciones que pueden
no ser finalmente ciertas– y planificar las adquisiciones –las estimaciones de las activi-
dades o paquetes de trabajo a subcontratar serán dato de partida para la solicitud de

ofertas–.
Estimaciones de los costes (Cost estimates)

Esta salida incluye las estimaciones cuantitativas de los costes posibles requeridos
para completar el trabajo de proyecto, así como las cantidades destinadas a reservas de
contingencia para prever riesgos identificados y las reservas de gestión establecidas frente
a trabajo no planificado, que sea necesario realizar al materializarse un riesgo no iden-
tificado.
El coste será estimado para cada actividad de la lista de actividades (activity list) que
cuelga, a su vez, de la EDT (WBS). Tiene en cuenta el trabajo directo, los materiales,
el equipo, los servicios, las instalaciones, la tecnología… y otras categorías especiales.
Esta salida, entre otras, será entrada a su vez en el proceso de:
• Identificar riesgos –las estimaciones se han realizado con un nivel de incerti-
dumbre y con una suposiciones que pueden no ser finalmente ciertas–.
• Y planificar las adquisiciones –las estimaciones de las actividades o paquetes de
trabajo a subcontratar serán dato de partida para la solicitud de ofertas–.
Bases de las estimaciones (Basis of stimates)

Si únicamente registramos el valor del coste, más adelante puede que no tengamos
claro qué incluía –en el caso de un aglomerado, si incluía el transporte, los controles de
calidad, el extendido…–.
Es por ello tan importante el valor del coste estimado como la documentación jus-
tificativa en la que nos hemos basado para estimarlo, las hipótesis que hemos conside-
rado, las restricciones existentes, la indicación de rangos de no actuación, los riesgos
identificados, los intervalos de confianza o el nivel de fiabilidad de la estimación final.
Esta salida será entrada a su vez en el proceso de «Elaborar el presupuesto».

Como resultado de la estimación de costes, puede surgir la necesidad de modificar
algún documento, como por ejemplo el registro de asunciones –si aparecen nuevos
supuestos o restricciones, o modificaciones de los inicialmente considerados–, así como
el registro de lecciones aprendidas.
3.7.3. Determinar el presupuesto

Es el proceso mediante el cual se establece una línea de base de coste autorizada
sumando los costes estimados de actividades individuales o paquetes de trabajo y exclu-
yendo las reservas de gestión. El cumplimiento de la línea de base del coste será un
posible indicador del éxito del proyecto.
En el proceso se agregan los costes estimados de cada actividad o paquete de trabajo,

más las reservas de contingencia, para establecer la línea de base autorizada respecto a la
cual se medirá el desempeño en costes del proyecto.
Es esencial, para un equipo de proyecto y su organización, elaborar y mantener un
presupuesto acordado y realista directamente asociado a un alcance de trabajo bien defi-
nido. Es clave también establecer medidas objetivas del desempeño en costes al elaborar
el presupuesto que aumenten la responsabilidad de su control por parte de cada depar-
tamento implicado.
En este esquema se ubica el proceso de elaboración del presupuesto –que constituirá
los fondos autorizados para ejecutar el proyecto– dentro de su área de conocimiento y
su grupo de procesos:
En este proceso se calculará el coste total del proyecto a partir de:

• los costes individuales de cada actividad, que
• agregados nos darán los costes de los paquetes de trabajo, y

• que agregados dan los costes de las cuentas de control, y
• la agregación de éstas, los costes totales del proyecto,
• a los que, no debemos olvidar, deben añadirse las reservas de contingencias para
llegar así a
• el valor de la Línea de Base del Coste del proyecto sobre la que el project
manager evaluará las variaciones en la fase de ejecución.
Añadiendo las contingencias de gestión (management reserves) –para riesgos no
previstos– se obtiene el presupuesto total del proyecto (project cost budget).
De esta manera el presupuesto total del proyecto será:
• la Línea de Base del Coste,
• más las contingencias gerenciales.
Por último, se comprobará el cashflow que surge de la integración de costes de
actividades y el cronograma de estas actividades ya que la distribución temporal de costes
permitirá:
• hacer una estimación de los costes previsibles en cada fase del proyecto, y
• mediante la curva de costes acumulados (curva S) podremos representar gráfi-
camente los gastos previstos totales del proyecto a lo largo del tiempo del pro-
yecto para que
• el departamento financiero consiga los fondos necesarios y negociarlos con las
entidades bancarias, en caso de que no se utilice capital propio.
En la gráfica siguiente se presenta un ejemplo de un caso de construcción de un
parque eólico donde se desglosa el coste de la obra civil (BOP) y los aerogeneradores:
Durante la fase de ejecución el seguimiento de costes reales nos permitirá ir com-

parando el dinero gastado hasta cierto momento con el que fue presupuestado.
En el esquema siguiente se presentan las entradas, herramientas y resultados de este
proceso:
En ISO21500 existe este mismo proceso con objetivos y resultados similares. Para la
ISO21500 tiene por objetivo distribuir el presupuesto entre los diferentes niveles de la EDT.
La asignación de presupuestos a paquetes de trabajo programados permite obtener un presupuesto
calendarizado respecto al que comparar la ejecución real.
Indica cómo la estimación de costes y la elaboración del presupuesto están muy relacionadas
ya que la estimación de costes determina el coste total del proyecto mientras que la elaboración
del presupuesto identifica cuándo y dónde se va a gastar.
Subraya la necesidad de establecer indicadores de desempeño de costes del proyecto al elaborar
el presupuesto para garantizar la asignación de responsabilidades y detectar a tiempo desvia-
ciones.
También considera la necesidad de establecer reservas de contingencia y/o gestión para
abordar riesgos previstos y/o imprevistos.
Entradas Salidas
Estimaciones de costes
Cronograma Presupuesto
Planes del proyecto
Cambios aprobados
DETERMINAR EL PRESUPUESTO (DETERMINE BUDGET):

Es el proceso mediante el cual se van acumulando los costes estimados para cada
una de las actividades individuales o paquetes de trabajo para establecer un presu-
puesto inicial y una línea de base del coste del proyecto autorizado.
El beneficio clave de este proceso es que determina la línea base de coste contra la
que se monitorizará y controlará el desempeño del proyecto.
ENTRADAS (INPUTS):
Para elaborar el presupuesto se tendrán en cuenta el plan de dirección de proyecto,

en particular el plan de gestión de costes –que define cómo se elaborará y controlará el
presupuesto–, el plan de recursos humanos del proyecto –donde encontraremos los
perfiles asignados al proyecto y sus costes– y la línea de base del alcance –alcance y
EDT–. También utilizaremos algunos Documentos del proyecto, como el cronograma
del proyecto, el calendario de recursos –para calendarizar los costes–, el registro de
riesgos –para incorporar los costes asociados a planes de contingencia o impactos de un
riesgo y los procesos, las estimaciones de costes de cada actividad y su documentación
–del proceso anterior–. También se atenderá a los Documentos de negocios (Caso de
negocio, Plan de gestión de beneficios), los acuerdos alcanzados con proveedores,
herramientas de control de gestión de costes, métodos de reporte,... establecidos por la
organización.

Plan de Gestión del Coste (Cost management plan)

Como se ha indicado es precisamente el documento en el que se indica cómo se
estructurarán los costes dentro del presupuesto y cómo se controlará su grado de cum-
plimiento.
Plan de Gestión de Recursos Humanos (Human resource management plan)

El Plan de gestión de los recursos humanos proporciona información sobre las tasas
de personal (coste/hora) y otros recursos, estimación de los costes de viaje y otros costes
previstos que son necesarios para estimar el presupuesto total de proyecto.
Con las horas asignadas por perfil de trabajador y sus costes horarios el project
manager podrá estimar el coste asociado a los recursos humanos de cada actividad. Los
niveles salariales y los bonus asociados a los objetivos del equipo afectarán al coste del
proyecto. Por ello, idealmente, el project manager debe tener acceso a estos datos.
Además de ayudarle a calcular el presupuesto de personal, le permitirá valorar la
idoneidad de un técnico más costoso pero rápido, o uno menos costoso pero menos
eficiente. Todo dependerá de si el proyecto tiene una restricción más fuerte en costes
(cost-driven project) o de plazo (time-driven project).
Como se comentó anteriormente, vemos en este caso la naturaleza iterativa del
proceso de planificación en la que para estimar los costes necesitaremos una definición
de perfiles y una asignación preliminar de recursos aunque, por ejemplo, tengamos que
afinarlas dependiendo del presupuesto final y los condicionantes financieros y de recur-
sos humanos.

Consensuada al inicio del proyecto, contiene el Enunciado del alcance del proyecto
(Project Scope Statement) –en el que pueden fijar unos costes máximos por período–,
la EDT y su Diccionario en el que se describe con más detalle el alcance y actividades
necesarias para completar cada paquete de trabajo, que serán de utilidad a la hora de
realizar la gestión y estimación de los costes.

Como ya hemos visto anteriormente, el cronograma incluye las fechas de inicio y
final de las actividades, hitos, paquetes de trabajo y cuentas de control. Esta información
permitirá agregar costes a los diferentes periodos, en los que se prevé que tengan lugar
los costes. Asimismo, permitirá poder establecer parámetros y fórmulas de financiación.
Estimación de costes (Cost estimates)

Resultado del proceso anterior, en el que se estimaban los costes para cada una de
las actividades, los costes son agregados para obtener el coste de los paquetes de trabajo.
Base de las estimaciones (Basis of estimates)

Documentación en la que nos hemos basado para estimar los costes y las hipótesis
que hemos considerado –supuestos de partida, formas de cálculo, si están incluidos o no
costes indirectos, etc.–.

Se revisará para ver cómo se agregarán los costes de los planes de respuesta a los
riesgos.
Documentos de Negocio (Business Documents)

Los documentos de negocio pueden influir en el proceso de determinar el presu-
puesto, ya que en ellos se pueden describir criterios requeridos, deseados y opcionales
para alcanzar las necesidades de negocio. Algunos de estos documentos a considerar
pueden ser:
Caso de negocio (Bussines case)

El caso de negocio identifica los factores críticos de éxito incluyendo los factores de
éxito financiero.
Plan de gestión de beneficio (Benefits management plan)

El plan de gestión de beneficios incluye los beneficios objetivo, tales como cálculos
de valor neto, periodos previstos para conseguirlos y las métricas asociadas a los mismos.
En caso de haber contratado productos, servicios o resultados (servicios externos
con consultores, proveedores de equipamientos o materiales, etc.). Los acuerdos con-
tendrán el alcance y el presupuesto de adjudicación para incluirlos en el presupuesto

total.

Los factores ambientales de la empresa a considerar en este proceso pueden ser: Las
tasas de cambio de moneda, y sus fluctuaciones, especialmente para proyectos que se
extienden durante varios años con distintas monedas, ser elementos necesarios a intro-
ducir en el proceso de determinar el presupuesto.

Si existen y están disponibles, pueden utilizarse plantillas definidas para:
• Elaboración de presupuestos, estandarizadas por la compañía para poder hacer
un seguimiento comparativo entre proyectos.
• Categorías de costes que la compañía utilice para clasificar.
• Registros de costes de otros proyectos similares,

• Repositorio de lecciones aprendidas
• Políticas, procedimientos, directrices, instrucciones para generar los presupues-
tos.
• Herramientas corporativas para preparar los presupuestos de costes.
• Métodos para la ejecución de informes.
Los costes estimados para las diferentes actividades del proyecto, así como las reservas
de contingencia para esas actividades se agregan obteniendo los costes de cada paquete
de trabajo. Los costes de los paquetes de trabajo, así como las reservas de contingencia
estimadas para esos paquetes de trabajo se agregan para obtener los costes a nivel de
cuentas de control. Esta agregación da la línea de base de coste. Las reservas de gestión,
para riesgos imprevistos, se añaden a la línea de base de coste para obtener el presupuesto
del proyecto.
Una vez que se tiene el presupuesto calendarizado, se compara con los condicio-
nantes de financiación lo que puede llevar a ajustar el cronograma.
El project manager debe apoyarse en el juicio experto de los departamentos res-
ponsables de ejecutar partes del trabajo y de otras partes interesadas relevantes, así como
de información y relaciones históricas que ayuden a estimar por analogía, paramétrica-
mente o al nivel del coste de cada actividad o paquete de trabajo ajustando estos valores
a la realidad del proyecto concreto.

Una vez calculado este presupuesto se puede acudir a expertos, proyectos análogos
o recabar información histórica de la empresa que, teniendo en cuenta las peculiaridades
del proyecto, contraste si el presupuesto calculado está dentro de un orden de magnitud
razonable.
Agregación de costes (Cost aggregation)

Las estimaciones de costes de las actividades serán agregadas, según la estructura de
la EDT, a fin de obtener los costes de los paquetes de trabajo (Work packages) que,
agregados proporcionan los costes de las cuentas de control (Control accounts) y por la
agregación de éstas obtendremos el coste total del proyecto.

Análisis de reservas (Reserve Analysis)
Se establecerán las reservas de gestión (o reservas gerenciales). Las reservas de gestión
son cantidades destinadas a asumir la realización para trabajo que, siendo necesario, no
está planificado en el proyecto, pero que está dentro del alcance del proyecto y por tanto
es necesario realizar.
Las reservas de gestión intentan cubrir los riesgos no identificados (unknown unk-
nowns) que pueden afectar al proyecto.
Las reservas gerenciales no forman parte de la línea de coste –ni se incluyen como
parte de los cálculos para la medición del Valor Ganado que se estudia más adelante–
pero sí del presupuesto del proyecto y de los requisitos de financiación. Cuando se utiliza
una cantidad de estas reservas de gestión, debe pasar a la línea base de coste, por lo que
debería requerirse la aprobación del cambio a la línea de coste.
Revisión de la información histórica (Historical information review)

Las estimaciones por analogía pueden apoyarse en datos históricos de proyectos
anteriores para construir modelos matemáticos que permitan predecir los costes totales
del proyecto. Serán más fiables conforme más parecido sea el proyecto a los anteriores,
el equipo tenga más experiencia, los modelos sean más fácilmente ajustables estadísti-
camente y su validez no dependa de si el proyecto es pequeño o grande.
Se suelen utilizar parámetros con los que establecer la comparación de unos pro-
yectos con otros, que posteriormente da lugar a la estimación. Dichos parámetros pue-
den ser muy sencillos (P.ej: Coste de construcción de un tipo determinado de vivienda
medido en €/m2, o complejos (P.ej. en estimaciones de costes de proyectos de desarrollo
de software, se utilizan múltiples parámetros de ajuste, para llegar a las estimaciones fina-
les).
Algunas claves para que los datos sean fiables de cara a su utilización en estimaciones,
son:
• Que la información histórica sea precisa
• Los parámetros a utilizar sean fácilmente cuantificables
• Los modelos sean escalables, y funcionan para proyectos grandes, pequeños o
fases.
Reconciliación del límite de financiación (Funding Limit reconciliation)

Básicamente consiste en comprobar que no se han rebasado los presupuestos dis-
ponibles para las diferentes categorías (personal, equipamiento…) y para las diferentes
fases del proyecto. Una diferencia entre los costes del proyecto y los límites de finan-
ciación puede llevar a una reprogramación de actividades y una modificación del cro-
nograma de proyecto.
Además, en caso de que se detecte un sobrecoste a tiempo, puede ser necesario
reconsiderar el alcance o los costes del proyecto o tratar de justificar ante el cliente un
aumento del presupuesto.
Financiación (Funding)
La financiación implica conseguir fondos para la ejecución del proyecto. Es habitual
tener que buscar financiación externa para proyectos con un cierto volumen. Cuando
hay financiación externa, la entidad que financia, puede imponer ciertos requisitos que
deberán ser cumplidos.
SALIDAS (OUTPUTS):
Se obtiene, por una parte, la línea de base del cronograma que será aprobada por
todas las partes interesadas relevantes que se comprometen a su cumplimiento, que
solamente podrá ser modificada mediante el proceso de control integrado de cambios
y que servirá de base para la comparación de los costes planificados con los reales. Por
otra parte, se obtienen las necesidades de financiación derivadas de la línea base de coste,
y actualizaciones a los documentos de proyecto. Estos resultados servirán de entradas
para, entre otros, el proceso de control de costes.
Línea de base de coste (Cost baseline)

La línea de base de coste es la versión aprobada del presupuesto calendarizado del
que se excluyen, las reservas de gestión –no así las reservas de contingencias asociadas a
riesgos identificados y planificados–, y que sólo debería ser modificada mediante el pro-
cedimiento formal de control de cambios establecido en el proyecto.
Se utilizará para comparar los resultados en cada momento del proyecto.
En la figura anterior se ve cómo se van agregando los diferentes costes:

• La agregación del nivel más bajo –las actividades y sus reservas de contingencia
identificadas–,
• nos da los costes de los paquetes de trabajo –y sus reservas de contingencia cómo
suma de las reservas de contingencias de las actividades de cada paquete de tra-
bajo–,
• y agregados estos, se llega al nivel que la organización haya definido las cuentas
de control –nivel en el que se hará el seguimiento de costes (y plazos) mediante
el método del Valor Ganado–,
• que agregados, a su vez, nos darán la línea de base de coste,
• de la que, si sumamos las reservas de gestión, se obtiene el presupuesto de coste.
Una vez calendarizado el presupuesto se obtiene una línea en forma de S, como una
fotografía de la planificación del presupuesto del proyecto antes de empezar. Esta Curva
S (S-Curve) de base se obtendrá sumando los costes aprobados por período de tiempo
(días, semanas, meses…).
En la fase de ejecución –ver figura siguiente– se podrán comparar los costes reales
con los costes previstos y, si las variaciones superan un límite establecido, identificar,
evaluar y seleccionar las actuaciones más adecuadas para reconducir el proyecto.
Para proyectos que utilizan la gestión del valor ganado (Earned Value Management),
nos referiremos a la línea base de coste como Línea base de desempeño de costes (Per-
formance measurement Baseline)
Estos resultados servirán de entradas para:
• el proceso de control de costes y
• el proceso de «Elaborar el Plan de Dirección de Proyecto».
Planificar la gestión de recursos humanos 305
Requisitos de financiación del proyecto (Project funding requirements)

Al departamento financiero de la organización no le bastará con el presupuesto
global. Para poder valorar las necesidades de financiación a corto, medio y largo plazo,
el project manager deberá entregar una tabla o gráfica que indique las necesidades de
fondos mensuales (deducidos del cashflow, ingresos-gastos del proyecto) para que el
departamento financiero estudie la fórmula más adecuada de financiación.
El project manager junto con el equipo financiero estudiará la fórmula que garantice
que el proyecto tenga los fondos adecuados en el momento en que se necesiten y que
estén suficientemente cubiertos los riesgos imprevistos o los incrementos por revisión
de precios si están previstos en el contrato.
Estos requisitos serán entradas para el proceso de control de costes.
Actualización de los documentos de proyecto (Project documents updates)

Una vez finalizado el proceso de elaboración del presupuesto es momento de inte-
grar en la documentación ya elaborada de la gestión del coste, los cambios y lecciones
aprendidas. Entre los documentos a actualizar cabe destacar el registro de riesgos, las
estimaciones de costes o el cronograma del proyecto.
3.8. PLANIFICAR LA GESTIÓN DE RECURSOS HUMANOS
Esta área de conocimiento incluye los procesos para organizar, gestionar y liderar el
equipo de proyecto. El equipo de proyecto lo forman las personas con roles y respon-
sabilidades asignados para la ejecución del proyecto. Mientras se produce la asignación
formal conviene que todos los miembros del equipo se impliquen en la planificación y
toma de decisiones relativas al proyecto. De esta manera se recogerá su experiencia y se
logrará su compromiso con el resultado.
También se encarga de la gestión de los recursos físicos (equipos, instalaciones,
hardware y software,…). En este caso, el project manager debe asegurarse de que los
equipos críticos están a tiempo y no retrasan el proyecto, debe evitar adquirir equipos
de mala calidad que comprometan los objetivos del proyecto y debe evitar tener un
inventario demasiado alto que repercuta en costes innecesarios.
La planificación y gestión de los recursos durante todo el proyecto de un proyecto
conlleva seis procesos: Planificar la gestión de recursos humanos (plan human resources
management) y Estimar los recursos para las actividades (Estimate activity resopurces)
durante la planificación, adquirir los recursos del proyecto (acquire resources team),
desarrollar el equipo de proyecto (develop project team) y dirigir el equipo de proyecto
(manage project team) durante su ejecución; por último Controlar los recursos (Control
resources) durante el seguimiento y control.
del PMBOK y la ISO21500 en lo que a gestión de recursos se refiere. En el siguiente cuadro
se reflejan los procesos de PMBOK y los de ISO21500 (estos últimos en cursiva):

Planificar los Adquirir el equipo de

Recursos Proyecto (Controlar los
(Establecer el Humanos Desarrollar el equipo de recursos)
(Estimar los recur- proyecto
equipo de pro- (Gestionar el
sos) Gestionar el equipo de
yecto) equipo de pro-
(Definir la organi- proyecto yecto)
zación del pro- (Desarrollar el equipo de
yecto) proyecto)
La planificación de los recursos humanos puede realizarse en dos etapas del grupo
de procesos de planificación:
• Tras definir el alcance del proyecto se puede proceder a realizar una primera
planificación de recursos, definir qué paquetes de trabajo se subcontratarán y
qué paquetes se harán dentro de la organización y a adquirir parte del equipo
de proyecto para que, entre otras cosas, apoye en la planificación del proyecto.
• Tras haber terminado los procesos de planificación del alcance, tiempo, costes,
calidad en los que ya se puede proceder a elaborar un Plan de Recursos Huma-
nos mucho más detallado a falta de aspectos como la asignación de la responsa-
bilidad de riesgos a los diferentes miembros del equipo.
La planificación de los recursos puede realizarse en dos etapas del grupo de procesos
de planificación:
• Tras definir el alcance del proyecto se puede proceder a realizar una primera
planificación de recursos, definir qué paquetes de trabajo se subcontratarán y
qué paquetes se harán dentro de la organización y a adquirir parte del equipo
de proyecto para que, entre otras cosas, apoye en la planificación del proyecto.
• Tras haber terminado los procesos de planificación del alcance, tiempo, costes,
calidad en los que ya se puede proceder a elaborar un Plan de Recursos mucho
más detallado a falta de aspectos como la asignación de la responsabilidad de
riesgos a los diferentes miembros del equipo.
Los procesos se presentan como diferenciados y secuenciales pero, en la realidad,
todos ellos interactúan entre sí y con los procesos de otras áreas como las de gestión del
alcance del proyecto (una variación en el alcance puede afectar a los recursos humanos
necesarios), la de riesgos (la política de seguridad y salud del personal, por ejemplo) o la
de tiempos (a mayor disponibilidad de recursos, si la tarea así lo permite, la duración de
la actividad será menor).
En definitiva, en este grupo de procesos se planifica los recursos realmente necesarios
para ejecutar las actividades del proyecto, se definen bien sus funciones y responsabili-
dades, se definen y cumplen sus necesidades de formación y se asegura que se mantienen
motivados y alineados con los objetivos del proyecto: (entre paréntesis y cursiva los procesos
correspondientes a ISO21500 que no se recogen como tales en PMBOK):
Aparece en ISO21500 dentro de los procesos de inicio de proyecto pero no en

PMBOK.
(Establecer el equipo de Este proceso tiene por objetivo adquirir los recursos necesarios para completar el
proyecto: Establish proyecto.
Project Team) Este proceso recoge aspectos del proceso «Planificar la gestión de recursos humanos»
–del grupo de procesos de planificación– y «Adquirir el equipo de proyecto» –del
grupo de procesos de ejecución– de PMBOK.
Donde se definen las necesidades de personal, los perfiles y capacidades
requeridas, se asignan sus funciones y responsabilidades y se define el
Planificar la gestión sistema salarial.
de recursos huma- En ISO21500 se proponen un proceso relacionado:
nos Definir la organización del proyecto
(Plan human Este proceso corresponde básicamente al proceso Planificar los recursos humanos
resource manage- del proyecto de PMBOK 6.ª Edición. Tiene por objetivo asegurar el compromiso
ment) de todas las partes implicadas en el proyecto. Se definen los roles, responsabilidades
y establecen los niveles de autoridad. Se define el organigrama del proyecto y los
flujos de reporte.
Tiene por objetivo determinar los recursos (personas, equipamiento, instalacio-
Estimar los recur- nes…) necesarios para completar cada actividad. Se realiza tras identificar las
sos: (Estimate actividades y previamente a estimar la duración de las mismas.
resources)
No hay diferencias significativas entre PMBOK y ISO 21500.
Una vez va a comenzar el proyecto, hay que confirmar el equipo final
del proyecto y el project manager deberá negociar con los directores
Adquirir el equipo funcionales los mejores recursos disponibles para el momento en que el
del Proyecto proyecto los demande.
(Acquire Project
team) Existe en los procesos de Inicio de ISO21500 un proceso parecido –Establecer
el equipo de proyecto– aunque tiene un carácter más de planificación. «Adquirir
el equipo de proyecto» de PMBOK busca adquirir el equipo definitivo.
Es la fase en la que el project manager forma al equipo, lo motiva y

Desarrollar el mantiene esta motivación para lograr un equipo coherente y enfocado
Equipo de proyecto a los resultados esperados en la que se hará una evaluación de su desem-
(Develop Project peño.
team)
No existen diferencias entre lo indicado en PMBOK 6.ª Edición e ISO21500.
Los conflictos que surjan en el proyecto deberá resolverlos el project
Dirigir el equipo de manager mientras mantiene al equipo enfocado en la obtención de los
resultados previstos.
proyecto
(Manage Project No existen diferencias entre lo indicado en PMBOK 6.ª Edición e ISO21500
team) salvo el hecho de que en ISO21500 está en el grupo de control y en PMBOK
6.ª Edición en el grupo de procesos de ejecución.
Controlar los recur- Se asegura que los equipos, instalaciones,… están disponibles a tiempo
y cumplen los requisitos definidos en el plan.
sos
(Control resources) No existen diferencias entre lo indicado en PMBOK 6.ª Edición e ISO21500.
Aspectos clave en la Gestión de Recursos

Personas
La implicación de todo el equipo de proyecto en la planificación es muy beneficioso.
Su participación en la definición del enfoque del proyecto aumento su compromiso con
el proyecto. El project manager debe ser un líder y un gestor y tener en cuenta la
localización geográfica de los miembros del proyecto, las comunicaciones con los
interesados, la gestión del cambio en la organización.
Recursos físicos
Debe asegurarse de que los equipos críticos están a tiempo y no retrasan el proyecto.
Debe evitar adquirir equipos de mala calidad que comprometan los objetivos del pro-
yecto. Debe evitar tener un inventario demasiado alto que repercuta en costes innece-
sarios
Tendencias
Existen diferentes tendencias que van teniendo cada vez más relevancia en la gestión
de proyectos:
• Los métodos de gestión de recursos (Kaizen, Just in time, TOC,…)
• Inteligencia emocional: El project manager debe aprender a conocerse para
mejor entender al equipo y ponerse en su lugar, mejorando así las relaciones y
la solución de conflictos.
• Equipos autoorganizados: Cada vez se delega más en equipos con mayor
responsabilidad y capacidad de auto-gestionarse. Esta tendencia es especialmente
relevante en las metodologías Agile
• Equipos virtuales/Equipos distribuídos: Cada vez es más normal que los
equipos no compartan espacio, que estén en oficinas, países o continentes dife-
rentes. Se logra así tener los mejores recursos pero implica retos de comunica-
ción, coordinación y compromiso.
Consideraciones para adaptar la gestión

No todos los proyectos se gestionan de igual manera. Dependerá de la diversidad,
medios físicos disponibles, cómo se adquieren los equipos de proyecto, la dificultad en
gestión de los equipos, los enfoques de ciclo de vida,…
Entornos ágiles o adaptativos

Los equipos autogestionados, en entornos colaborativos, son claves en proyectos
con altos grados de variabilidad e incertidumbre
3.8.1. Roles y responsabilidades en un proyecto
El equipo de dirección (Project management team)

El equipo de dirección es una parte del equipo de proyecto y será responsable de
liderar y dirigir el proyecto en las diferentes fases del proyecto. Entre ellos, un elemento
importante será el patrocinador (sponsor) que trabajará con el equipo de dirección y
colaborará en la búsqueda de financiación, en la resolución de conflictos con el cliente
y también con otros interesados.
El equipo de Dirección deberá ejercer su influencia positiva en el equipo tratando
de generar buen ambiente, buscar la mejor ubicación, y creando flujos de comunicación
eficientes así como teniendo en cuenta la cultura de la empresa y los asuntos de orden
multicultural de los componentes del equipo.
Si bien a lo largo del documento se van desgranando las responsabilidades de cada
participante en el proyecto, a continuación se hace una síntesis de las responsabilidades
generales de los actores más importantes.
Responsabilidades del patrocinador (Sponsor)

Es una figura muy importante en la gestión de proyectos y de su implicación depen-
derá buena parte del éxito del proyecto.
Sus funciones y responsabilidades se reparten en las fases de:
• Inicio: Lidera el inicio del proyecto, recoge los requerimientos propios y del
cliente, es el portavoz ante el cliente y es la máxima autoridad del proyecto.
Elabora el Acta de Constitución en la que autoriza el proyecto y nombra el
project manager quien colabora en su elaboración y cierre –si, como es reco-
mendable, ha sido designado ya– y garantiza el alineamiento de los objetivos del
proyecto con los estratégicos de la empresa.
• Planificación: En esta fase su labor es la de facilitar al project manager y el equipo
de proyecto su trabajo de planificación suministrándoles el tiempo y la infor-

mación que requieren, dándoles consejos, buscando el equilibrio entre objetivos
y prioridades confluyentes y aprobando el Plan de Dirección del Proyecto.
• Ejecución y Seguimiento y Control: En esta fase mantiene su papel de líder y
responsable final del proyecto ante la alta dirección y el cliente, resuelve con-
flictos que estén fuera del alcance del project manager y aprueba los cambios –
salvo que los delegue en una Comisión de Control de Cambios (Change Con-
trol Board)– y vela porque los objetivos y alcance del Acta de Constitución no
se alteren –ya que implicaría un cambio muy importante–. El sponsor es la única
persona autorizada para aprobar cambios en el Acta de Constitución previo
acuerdo con el cliente, si no coinciden en la misma persona.
• Cierre: En esta fase aprueba los entregables antes de ser enviados al cliente y se
asegura que el cierre administrativo se realice correctamente antes de liberar los
recursos asignados al proyecto.
Responsabilidades del project manager

En términos generales tiene las funciones de un gerente o director general de una
empresa que dura un tiempo concreto, el plazo del proyecto, por lo que, una vez tenga
el Enunciado del Alcance del trabajo, deberá:
• Planificar el trabajo (qué hay que hacer) no olvidando ninguna de las áreas de
conocimiento (coste, tiempo, riesgos, recursos humanos…) y muy especial-
mente la de integración.
• Organizar el trabajo (con qué recursos, de qué manera).
• Tomar decisiones de inicio del trabajo y de sucesivos paquetes de trabajo
siguiendo el sistema de autorización de inicios de trabajo establecido por la
compañía.
• Supervisar, comprobando que se está ejecutando el proyecto según los criterios,
estándares y procesos establecidos.
• Controlar, lo que lleva a medir tanto el desempeño del proyecto como el de
cada miembro del equipo, para comparar con lo inicialmente previsto y, si
encuentra desviaciones, estudiar su impacto global en el proyecto y, si procede,
proponer cambios.
• Crear compromiso con el proyecto y espíritu de equipo, formar y capacitar al
equipo, mantenerlo informado de decisiones clave, cambios, datos que afecten
a su trabajo, evaluar su rendimiento y desarrollo profesional y, si procede, pre-
miarles de acuerdo al sistema de recompensas y beneficios establecidos.
Entre las responsabilidades del project manager en el área de recursos humanos des-
tacan las siguientes:
• Crear un Directorio del equipo de proyecto.
• Negociar con los jefes funcionales los mejores recursos disponibles.
• Crear descripciones del puesto de trabajo para los miembros del equipo de pro-
yecto y otros interesados.
• Identificar las necesidades de formación del equipo de proyecto y asegurarse de

que reciben la formación necesaria que, hay que subrayar, es responsabilidad del
project manager.
• Crear un plan formal con la involucración del equipo en el proyecto y las fun-
ciones que desempeñarán cada uno de sus miembros.
• Realizar informes de desempeño de los miembros del Equipo de proyecto e
incorporarlos al sistema de evaluación del personal de la compañía.
• Asegurarse de que se tratan de resolver las necesidades del equipo.
• Crear los sistemas de reconocimiento y recompensas descritos en el Plan de
Gestión del Personal.
Responsabilidades del equipo de proyecto

El equipo de proyecto debe ejecutar los paquetes de trabajo asignados, asegurarse
de que comprende bien el alcance y conoce las restricciones del trabajo, crea la EDT,
el diagrama de red, estima costes y tiempos… todo ello con ayuda del project manager.
Se responsabiliza de su parte de trabajo asignada para lo cual la revisará antes de enviarla
al project manager para su aprobación.
Responsabilidades del director funcional

Es el responsable de los recursos humanos procedentes de su departamento. Le
corresponderá la asignación de los recursos adecuados de entre los disponibles. Tratará
de hacerlo de manera consensuada y negociada con el project manager, para así lograr
un cronograma y una asignación temporal de recursos que satisfaga y pueda ser aprobada
por ambas partes. Debido a su experiencia concreta en el área técnica específica de su
departamento, apoyará al equipo y al project manager en todos aquellos momentos que
éstos le requieran.
3.8.2. Planificar la gestión de recursos humanos

Este proceso tiene como objetivo identificar y documentar los roles y responsabi-
lidades del proyecto, las habilidades requeridas, las relaciones y flujos de reporte y crear
un Plan para gestionar los recursos.
Los roles pueden designarse a personas o grupos y pueden proceder de dentro y de
fuera de la organización lo que afectará a la competencia por los recursos dentro de la
organización y a los costes, cronograma, riesgos, calidad...del proyecto.
En esta fase se identifican y documentan:
• Las necesidades de recursos humanos
• Los roles, autoridades, responsabilidades y habilidades dentro de un proyecto
• Las habilidades y capacidades requeridas
• Las relaciones de comunicación y reporte
Y se identifican y documentan también
• Las necesidades de recursos físicos (equipos, instalaciones,…)
• Los mecanismos para asegurar que están a tiempo y son adecuados a las nece-
sidades del proyecto
Para finalmente crear el plan de gestión de los recursos
Además de los roles y responsabilidades, necesidades de recursos físicos,… y de un
organigrama de proyecto, el plan de gestión de los recursos del proyecto incluye un
cronograma con las necesidades de recursos del proyecto (con entradas y salidas
de personas).
Como se indicó en la introducción al proceso de planificación y sus actividades, una
vez que se habían recogido los requerimientos del proyecto y definido el alcance del
proyecto, se hizo:
• Una primera identificación tanto de los paquetes de trabajo que eran susceptible
de subcontratarse.
• Y una primera definición y selección del equipo de proyecto que se encargaría
de realizar los trabajos que se harían con personal interno.
Esa primera asignación es siempre recomendable para que el equipo que sea nom-
brado al principio participe en las primeras etapas y se comprometa y haga suyo el
proyecto y sus objetivos.
En este momento, tras haber definido:
• El alcance
• El coste
• El presupuesto
• Las actividades de calidad
procede definir con todo detalle el Plan de Gestión de Recursos y completar los
aspectos relativos a cómo organizar, gestionar y dirigir al equipo de proyecto y asegurar
que los equipos, instalaciones,… están disponibles cuándo y cómo se necesitan para el
proyecto. El equipo de proyecto estará compuesto por las personas anteriormente defi-
nidas –con las actualizaciones que se consideren necesarias fruto de la planificación del
alcance, coste, tiempo y calidad y los cambios que se hayan podido producir en la com-
pañía–. A cada una se les asignarán sus roles y responsabilidades precisas para ejecutar el
proyecto.
Para elaborar el Plan de Recursos se partirá del Acta de Constitución, el Plan de
Dirección del Proyecto (en el que ya estarán integrados los planes de gestión del alcance,
tiempo, coste y calidad), los documentos de proyecto y se tendrán presentes los factores
ambientales de la empresa y los activos de los procesos de la organización. Con todo
ello se abordan dos objetivos principales:
• Identificar y documentar los roles, responsabilidades y relaciones de dependen-
cia en el proyecto.
• Crear el Plan de Gestión de Recursos
De acuerdo a A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
– Sixth Edition, Project Management Institute, Inc., 2017 en este proceso:
• Se identifican y documentan los roles, responsabilidades, habilidades requeridas,

relaciones de comunicación necesarias y organigramas de proyecto.
• Las necesidades de recursos físicos (equipos, instalaciones,…) y los mecanismos
para asegurar que están a tiempo y son adecuados a las necesidades del proyecto
• Y se elabora el Plan para la Gestión Recursos –que podrá incluir estrategias para
fomentar el espíritu de equipo, los planes de reconocimiento…–.
Hay que prestar especial atención a la disponibilidad de los recursos que pueden
estar en competencia con otros proyectos de la empresa con mayor o menor prioridad.
Los miembros del equipo tienen que tener bien claro:
• Qué paquetes de trabajo y qué actividades tienen asignadas.
• Qué capacidades y habilidades deben tener (y facilitarles la formación necesaria).
• Saber cómo se va a evaluar el éxito de su trabajo estableciendo indicadores claros.
• Qué información necesitan y quién se la va a entregar.
• Qué información necesitan otras personas de ellos y cuál es el formato, conte-
nido y periodicidad en que se la deben enviar.
• Cuál es su grado de implicación en aspectos transversales concretos del proyecto

como la gestión de riesgos, de costes…
El siguiente esquema ubica el proceso dentro de su área de conocimiento de gestión
de los recursos y su grupo de procesos:
Mediante este proceso el project manager define y documenta:

• las funciones o roles y responsabilidades individuales y de grupos para cada uno
de las tareas o labores que conlleva el proyecto, así como
• los flujos de información y relaciones de reporte dentro del proyecto.
Los recursos humanos podrán ser:

• personal interno de la empresa, en plantilla, o
• personal externo, como proveedores, asesores técnicos…
El plan de gestión de recursos debe asegurarse también de que los equipos críticos
están a tiempo y no retrasan el proyecto. Debe evitar adquirir equipos de mala calidad
que comprometan los objetivos del proyecto. Debe evitar tener un inventorio dema-
siado alto que repercuta en costes innecesarios.
El Plan de Gestión de Recursos (Resource management plan) y el Plan de Comu-
nicación (communications plan) están muy relacionados y ambos planes deberán ela-
borarse de forma conjunta y coordinada.
Al desarrollar el Plan de Recursos el project manager debe tener en cuenta varios
factores como:
• La disponibilidad de recursos.
• Sus niveles de capacidad, formación y experiencia.
• Sus necesidades de formación para cumplir con las funciones que se esperan de
él.
• Los riesgos no previstos surgidos del perfil y composición de los recursos asig-
nados.
• La disponibilidad en la propia empresa o en el mercado de los equipos e insta-
laciones necesarias.
En el siguiente esquema se observa de forma esquemática los datos de entrada nece-
sarios, las técnicas y herramientas más comúnmente utilizadas y el resultado esperado de
este proceso: el Plan de Recursos que incluye la definición de funciones y responsabi-
lidades, los cuadros organizativos,…
En ISO21500 existen tres procesos que recogen en parte los objetivos y contenidos del
proceso «Planificar la Gestión de Recursos Humanos» de PMBOK:
1. Establecer el equipo de proyecto (en el grupo de procesos de inicio)
Tiene por objetivo determinar cómo y cuándo se van a adquirir los miembros del equipo de
proyecto. En la tabla siguiente se presentan las entradas y salidas (no define ni técnicas ni
herramientas) que propone ISO21500 para este proceso:
Entradas Salidas
Requerimientos de recursos
Organigrama del proyecto Asignaciones de recursos
Disponibilidad de recursos Contratos de personal
Planes de proyecto
Descripción de roles
2. Estimar los recursos (en el grupo de procesos de planificación)

Tiene por objetivo determinar los recursos necesarios –personal, equipamiento, instalacio-
nes…– para cada actividad.
Entradas Salidas
Lista de actividades Requerimientos de recursos
Planes de proyectos Plan de Recursos
Cambios aprobados
3. Definir la organización del proyecto (grupo de procesos de planificación)

Tiene por objetivo asegurar el compromiso de todas las partes interesadas para adquirir el
equipo definitivo.
Se deben definir los roles, responsabilidades y poderes relevantes para el proyecto teniendo
en cuenta la naturaleza y complejidad del proyecto, así como las políticas existentes en la
organización.
La definición de la organización incluye la identificación de todos los miembros del equipo
y personas a implicar en los trabajos del proyecto así como la asignación de responsabilidades,
que deberán realizarse al nivel adecuado de la EDT.
Entradas Salidas
Planes de proyecto
Estructura de desglose del Trabajo Descripción de roles
Requerimientos de recursos Organigrama de proyecto
Registro de partes interesadas
Cambios aprobados
PLANIFICAR LA GESTIÓN DE RECURSOS (PLAN RESOURCE

MANAGEMENT)
Se identifican y documentan las funciones y responsabilidades dentro de un pro-
yecto, las habilidades y capacidades requeridas y las relaciones de comunicación y

reporte, los equipos, instalaciones y otros recursos físicos y se crea el Plan de Recursos
del equipo.
ENTRADAS (INPUTS):
Entre la información a tener en cuenta están el Acta de Constitución, el Plan de

Dirección del Proyecto –en el que se define el ciclo de vida del proyecto y los procesos
de gestión de proyectos que se van a aplicar a esta fase, y se define cómo se va a ejecutar
el trabajo necesario para lograr los objetivos del proyecto...–, los documentos de pro-
yecto que se van generando como el registro de riesgos o el de supuestos y los factores
ambientales de la organización –cultura y estructura, recursos humanos disponibles,
políticas de recursos humanos vigentes...– y los activos de los procesos de la organización
–descripciones de roles existentes, plantillas de organigramas y matrices de asignación
de responsabilidades, información histórica y lecciones aprendidas sobre gestión de

recursos en proyectos anteriores...–.
Acta de Constitución (Project Charter)

Describe los requisitos y características de alto nivel del proyecto, la justificación y
objetivos y puede recoger elementos clave a tener en cuenta para planificar bien los
recursos críticos.

En el Plan de Dirección del Proyecto se define el ciclo de vida del proyecto y los
procesos que se van a abordar para gestionar el proyecto así como el grado de detalle
en que se hará, información que permitirá, entre otras cosas, dimensionar adecuada-
mente el equipo de dirección de proyecto. Icluirá la línea de base en la que está el trabajo
que hacer y nos indicará la mejor forma de abordar la gestión de recursos para lograrlo.
Documentos de proyecto (Project Documents)

El cronograma del proyecto, la documentación de requisitos, el registro de riesgos,
el registro de interesados,… son documentos que se irán generando y darán información
valiosa para ver cómo abordar la gestión de recursos.

La cultura y estructura organizativa de la empresa es muy importante y se refiere al
lenguaje común, conocimientos técnicos, tipo de relaciones entre los empleados… que
existen y que el project manager debe tener en cuenta.
Dependiendo del tipo de organización en la que se trabaje, el sector en que desarrolle
la actividad y muchos otros factores, las relaciones laborales serán diferentes y deberán
tenerse en cuenta a la hora de desarrollar el Plan de Gestión de Recursos.
Los factores más relevantes que pueden afectar a la elaboración del Plan de Gestión
de Recursos son:
Los factores organizativos:

En este apartado se encuentran:
• Las plantillas de trabajo.
• Las lecciones aprendidas en proyectos anteriores.
• Los departamentos o unidades funcionales que se verán afectadas positiva o
negativamente.
• Las relaciones y flujos de información y reporte entre equipo y departamentos.
• La cultura empresarial con relaciones formales o informales y una estructura
rígida o flexible.
Recursos humanos disponibles del mercado de empleo:

Habrá que tener en cuenta las habilidades, capacidades y aptitudes del personal pro-
pio y valorar si están preparados o pueden estarlo con la debida formación o, si es nece-
sario, hay que contratar personal o servicios externos.
Las condiciones del mercado laboral o de la prestación de servicios en el sector –en
época de crisis, mucha oferta y barata, en época de bonanza, poca oferta y cara– también
afectarán a la planificación de los recursos humanos.
Políticas de personal:
El project manager deberá tener en cuenta la política de recursos humanos de la
empresa en aspectos como los procesos de contratación, la asignación de trabajos o las
condiciones laborales –vacaciones, días por asuntos propios, horarios laborales…–.
Factores técnicos:
Dependiendo de la organización y el proyecto, la capacidad técnica en aspectos muy
especializados será crítica. Esto se deberá tener en cuenta en la realización el trabajo, en
la transición entre fase y fase y en la entrega e instalación, si procede, al cliente.
Factores interpersonales:
No solamente se deberá evaluar las capacidades, habilidades y conocimientos téc-
nicos del equipo sino el nivel de confianza y respeto para con los compañeros y supe-
riores: puede haber personas muy preparadas técnicamente pero con muy poca capaci-
dad de trabajo en equipo.
Ubicación:
No será igual gestionar un proyecto donde todos los miembros del equipo están
ubicados en la misma planta, en el mismo edificio, en la misma ciudad, que si están en

otra ciudad o país –con horarios de trabajo diferentes– donde, como se verá en el apar-
tado siguiente, el Plan de Comunicación, las requisitos de comunicación, los medios y
las tecnologías serán muy diferentes.
Factores políticos:
En este apartado aparecen con especial relevancia las partes interesadas (clientes,
promotores, alta dirección, proveedores, equipos de trabajo, jefes funcionales…) con
sus relaciones cruzadas y sus expectativas en competencia.
Asimismo deberá tener en cuenta tres restricciones importantes:
Las estructuras organizativas:

Se ha comentado que en las organizaciones jerárquicas –matriz débil (weak matrix)–
el poder, de asignación de los recursos muy especialmente, lo tiene el director funcional,
mientras que en la organización enfocada a proyectos (projectised) o matrices fuertes

(Strong matrix) lo tiene el project manager.
En una matriz equilibrada el poder está repartido por igual entre el project manager
y el director funcional, cada uno con sus responsabilidades y la asignación de personas
al proyecto se hace según las necesidades del proyecto y no según el poder relativo de
cada uno.
Los convenios laborales sindicales:

En unos países más que en otros este aspecto es fundamental a la hora de establecer
el Plan de Recursos ya que acotarán el margen de maniobra para reubicar personal entre
centros, entre proyectos, entre tareas y responsabilidades y condicionarán las políticas
de recompensas y premios.
Las condiciones económicas:

El acceso a financiación adecuada a las necesidades del proyecto depende fuerte-
mente de las condiciones económicas. Esta financiación afectará al presupuesto total y
a presupuestos particulares como formación, contratación y viajes.
En definitiva, es clave que el project manager, a la hora de establecer su Plan de
Recursos, tenga en cuenta los factores ambientales de la empresa y las restricciones
indicadas en este punto, puesto que pueden tener un impacto positivo o negativo en el
desarrollo del plan.

Los principales datos de entrada relativos a los activos de los procesos de la organi-
zación son:
• Los procesos organizativos.
• La definición de roles y perfiles.
• Las plantillas (descripciones de proyectos, matrices de asignación de responsa-

bilidades, evaluaciones del desempeño y resultados finales del proyecto, procesos
de gestión de conflictos…).
• Las listas de control para no olvidarse la consideración de ningún elemento de
los expuestos.
• La información histórica de proyectos precedentes.
Con el objetivo de asegurar que cada paquete de trabajo tiene un único propietario
y que todos los miembros del equipo tienen claros sus roles y responsabilidades en el
proyecto, se pueden utilizar, entre otros aspectos:
• Estructuras de desglose de la organización –organigramas de proyecto estruc-

turados por departamentos bajo los cuales se listan las actividades o paquetes de
trabajo que deben ejecutar–.
• Matrices de asignación de responsabilidades –en las que a cada paquete de trabajo
se le asigna un(os) responsable(s) de hacerlo, un único responsable de que se
haga, a quien hay que consultar y a quien hay que informar–.
• Descripciones de perfiles, autoridades, competencias y responsabilidades.

Se consultará a expertos para, por ejemplo, listar los requerimientos preliminares de
las habilidades necesarias, evaluar los roles requeridos para el proyecto en base a des-
cripciones estándar de puestos que haya en la organización, determinar las relaciones de
reporte necesarias teniendo en cuenta la cultura de la organización o identificar riesgos
asociados a la adquisición, retención y liberación del personal. Asimismo permitirán
hacer una primera evaluación de cómo enfocar la identificación de recursos físicos
necesarios y cuál es la mejor manera de contratarlos.
Representación de datos (Data representation)

Se pueden utilizar muchos formatos para recoger la información relativa a los recur-
sos necesarios.
Organigramas (Organization charts) y Descripción de puestos (Position descriptions)

Son esquemas organizativos en los que se indica el nombre, puesto y jefe jerárquico
de cada persona. Muestran las relaciones entre directores, miembros del equipo, y otras
personas de dentro y fuera de la compañía que trabajarán en el proyecto.
También se realizan organigramas, más específicos, para ver cuál es el equipo que
se responsabilizará de los riesgos o del aseguramiento de la calidad.
Su principal objetivo es asegurar que cada paquete de trabajo tenga un responsable

inequívoco y que sea comprendido y asumido claramente por el responsable.
Con estos elementos es fácil seguir quién reporta a quién y qué es lo que hace cada
persona de la compañía afectada por el proyecto. Puede representarse de varias formas:
Organigrama jerárquico (Hierachical chart)

Se muestran en un formato arriba-abajo (top-bottom) comenzando por la alta
dirección y acabando por los empleados de nivel inferior.
Una estructura de desglose de la organización (organizational breakdown structure,
OBS) es un tipo particular que muestra los departamentos, las unidades de trabajo o los
equipos (no personas) de una organización y los respectivos paquetes de trabajos asig-
nados.
Para desarrollar una estructura jerárquica de una organización se suelen dar los
siguientes tres pasos:
1. Dibujar la organización completa de forma jerárquica.

2. Definir todos los departamentos y los equipos de proyecto.
3. Especificar grupos funcionales –donde el coste del trabajo se va a imputar– y
grupos de aprobación –quien aprueba el trabajo–.
El siguiente esquema sería un ejemplo de OBS:
Una estructura de desglose de recursos (resources structure breakdown, RBS)

muestra el trabajo del proyecto de acuerdo al tipo de recursos necesarios (programadores,
gestores de cuenta, escritores, editores, analistas, calculistas, supervisores…).
Esta estructura puede ayudar al seguimiento y gestión de costes del proyecto al
definir perfiles-tipo de empleado, siempre que estén relacionados con la estructura de
contabilidad de la organización. Puede incluir categorías de recursos que no sean recur-
sos humanos sino materiales, equipos, programas…
Dos ejemplos serían los siguientes –tipo matricial y tipo jerárquico–:
Organigrama matricial
Se utilizan para representar los recursos (o los departamentos o puestos, si no hay
una asignación definitiva de nombres concretos a proyecto). Pueden tomar dos formas
diferentes:
• Matriz de asignación de responsabilidades (Responsabilities Assignment Matrix,
RAM).
Ilustra las relaciones entre las actividades o paquetes de trabajo y los miembros del
equipo (en proyectos más simples) o departamentos de la organización (en proyectos
complejos). Representa gráficamente esta información y suelen colocarse los recursos
en una fila y los paquetes de trabajo o fases o actividades en columnas. Los puntos de
intersección indican si ese recurso participa y cómo en esa actividad.
Un ejemplo real de este tipo de matrices podría ser el siguiente, en el que se definen
las responsabilidades para elaborar los diferentes componentes de una oferta económica:
• Matriz RACI (Responsible, Accountable, Consulted, Informed):

Es un ejemplo de matriz RAM. En ésta se representa el nivel de responsabilidad de
cada participante en el proyecto siendo éstas:
R: responsable de realizar el trabajo.
A: quien rinde cuentas, el responsable final de que el trabajo esté realizado tal y
como debía y en el plazo previsto, y lo aprueba firmándolo.
C: persona consultada, para tomar decisiones sobre el trabajo, aportar informa-
ción o colaborar.
I: Persona que debe ser informada de las decisiones y resultados.
Este diagrama tiene especial relevancia cuando el equipo está formado por recursos
internos y externos para así asegurar una diferenciación clara de roles y expectativas.
Un ejemplo sencillo de este tipo sería el siguiente:
Daniel E. Ana C. Paula G. María F.
Definición de requisitos R A C C
Definición alcance I C R A
Desarrollo A R I C
Implantación C I A R
Otros tipos: el formato tipo texto

También se pueden representar mediante formularios de descripción de roles que
incluyan detalles como la función, la responsabilidad y la autoridad de cada recurso.
Funciones y responsabilidades en otros Planes Subsidiarios

Conviene tener en cuenta que otros Planes Subsidiarios pueden tener también defi-
niciones de funciones y responsabilidades como son el Plan de Gestión de los Riesgos
del Proyecto, el Procedimiento de Gestión de Cambios o el de Gestión de la Calidad.
Teorías de la organización (Organization Theories)

Son aquellas que tratan de explicar los mecanismos por los que las personas inter-
actúan de una manera u otra y son más o menos eficientes en una organización u otra
y hacen propuestas organizativas en función de los factores ambientales e internos de la
empresa.
Juicio de expertos (Expert Judgement)

Se utilizará el juicio experto para definir los requerimientos de competencias y
habilidades del equipo, evaluar los roles y responsabilidades necesarios para el proyecto
teniendo en cuenta los definidos a nivel organizativo, determinar las relaciones de
reporte, toma de decisiones y escalado, identificar riesgos asociados a los recursos huma-
nos y físicos, muy especialmente aquellos que se consideren críticos…
Lógicamente una de las formas más efectivas de obtener el juicio de expertos y otras
partes interesadas relevantes en lo que a la planificación y gestión de recursos se refiere
serán las reuniones.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtiene el Plan de Gestión de Recursos que

establecerá cómo se van a definir, asignar, gestionar, y, eventualmente, liberar los recur-
sos humanos de proyecto. Este plan suele incluir una descripción de roles y responsa-
bilidades, un organigrama de proyecto en el que se muestren los miembros del equipo
de proyectos y sus relaciones y flujos de reporte, una matriz de asignación de respon-
sabilidades y un Plan de Gestión del Personal de proyecto que describirá cuándo y cómo
se incorporarán los miembros del equipo y cómo se lograrán los recursos necesarios para
el proyecto. También se preparará un Team Charter, donde se recogerán los derechos
y deberes del equipo para que tenga un funcionamiento adecuado. Como resultado del
proceso será necesario actualizar algunos documentos de proyecto (registro de riesgos,
línea de base de costes,…)
Plan de Gestión de Recursos (Resource management plan)

Identificación de Recursos
Se definirán los métodos para identificar los recursos existentes
Adquisición de recursos
Se darán directrices sobre cómo, cuándo adquirir los recursos externos necesarios
Roles y responsabilidades
Cada puesto en el proyecto debe ser definido, tiene un título, una autoridad para
realizar o decidir determinadas cuestiones y/o es responsable de unos entregables espe-
cíficos.
Esta definición puede tomar la forma de cualquiera de las matrices, estructuras
jerárquicas o formularios descritos en el apartado de técnicas y herramientas. Cada des-
cripción deberá incluir los siguientes aspectos:
• Función (role): de qué parte del proyecto es responsable cada equipo-persona.
• Poder (authority): la capacidad que tiene el equipo o persona para tomar deci-
siones pudiéndose dar una gradación en función de la relevancia, características
e impacto de la decisión –por ejemplo, capacidad de autorizar compras por
niveles de presupuesto–.
• Responsabilidad (accountability): el trabajo que se debe realizar para completar
las actividades asignadas y del que debe rendir cuentas (be accountable).
• Competencia (Competence): describe las habilidades y capacidades para realizar
las actividades asignadas.
Cuando se identifican desequilibrios entre la competencia requerida y la real del
miembro del equipo, se inician acciones de capacitación, contratación o cambios en el
organigrama reasignando y redistribuyendo al personal de acuerdo a sus competencias.
Organigrama del proyecto (Project organization chart)

Es una representación gráfica de los miembros del equipo y sus relaciones de comu-
nicación. Muestra la estructura de reporte de los recursos asignados al proyecto. Es como
el organigrama de la compañía pero aplicado a las personas asignadas al proyecto con-

creto. Podrá ser más menos detallado y más o menos formal en función de la duración,
complejidad y tamaño del proyecto.
Es importante destacar que este organigrama puede incluir personas y relaciones que
no estén necesariamente en el organigrama de la compañía como algunas partes intere-
sadas, los proveedores, los consultores…
La gestión de recursos del equipo de proyecto

Directrices sobre cómo se van a definir. Asignar, gestionar y finalmente liberar los
recursos humanos del proyecto
Las necesidades de formación

Para quien no tenga las habilidades necesarias se identificarán las necesidades de
formación que cubran el desfase entre capacidades y requerimientos del puesto. En este
sentido puede ocurrir que la compañía tenga un magnífico técnico en una especialidad
y que se le proponga como project manager. Si no tiene la formación específica de

project manager, habrá que dársela y entrenarle en las nuevas habilidades requeridas. Si
no, podemos caer en el efecto Halo (pensar que un muy buen técnico debe necesaria-
mente ser un buen gestor).
Desarrollo del equipo

Métodos para lograr desarrollar y hacer crecer al equipo y que vaya pasando por las
fases del ciclo de Tuckman (Formación, turbulencias, normalización y desempeño de
forma constructiva)
Control de recursos
Métodos para asegurar que los recursos físicos están disponibles, cuando se necesitan
y que son adecuados a su uso para el proyecto.
El sistema de reconocimientos y recompensas

Será una parte importante del plan para mantener al equipo motivado. Un sistema
de premios directamente asociados a los resultados de sus tareas es una buena manera de
lograrlo. Debe haber criterios claros, basarse en las actividades que están a su cargo y
sobre las que tiene capacidad de actuación. Esta parte está incluida dentro del proceso
de desarrollo del equipo del proyecto. El ideal es que el project manager tenga respon-
sabilidad y autoridad en la definición del plan de recompensas y reconocimientos y en
su ejecución.
Carta de derechos del equipo (Team Charter)

Debe ser un documento que establezca las reglas básicas de funcionamiento del
equipo, lo que está permitido y lo que no, que garantice que quedan claras las expec-
tativas de funcionamiento del equipo. Incluye entre otras cosas (para dejar claras las reglas
de juego en el equipo y centrar las expectativas dentro del equipo):

• Los valores del equipo
• Las directrices de comunicaciones
• Los procesos y criterios para tomar decisiones
• Los procesos de resolución de conflictos
• Las guías para tener reuniones efectivas
• …
Actualización de los documentos de proyecto (Project documents update)

Los documentos de proyecto, que en todos los casos se van actualizando conforme
a las necesidades, pueden tener que actualizarse de acuerdo a lo acordado en el plan de
gestión de recursos; por ejemplo, el registro de supuestos (qué tipo de recursos supo-
nemos que podremos tener) o el registro de riesgos (de no contar con los perfiles que
necesitamos para llevar adelante el proyecto).
3.8.3. Estimar los recursos de las actividades

Una vez secuenciadas las actividades, se estiman el tipo y cantidad de material,
equipos, personas…, necesarias para realizar cada actividad de tal manera que permitan
una estimación de plazos y costes más precisa. Su principal beneficio es que identifica
el tipo, cantidad y características de los recursos necesarios para completar cada actividad,
lo que permitirá una estimación de duraciones y costes mejores.
Deben ser bien planificados para evitar que no estén disponibles cuando sean nece-
sarios porque, por ejemplo, estén ocupados en otros proyectos. Este proceso consiste,
según Project Management Institute, A Guide to the Project Management Body of Knowledge
(PMBOK® Guide) – Sixth Edition, Project Management Institute, Inc., 2017, en esti-
mar el tipo y cantidades de materiales, personas, equipos o suministros para ejecutar cada
actividad.
Antes de definir el cronograma en el que ya se indiquen las tareas y sus duraciones
así como el plazo final del proyecto, se necesita saber con qué recursos se cuenta y qué
recursos se necesitan, ya que la duración será normalmente función del número de
recursos asignados.
Los recursos incluyen las personas que van a dedicar horas de su jornada al proyecto
y los equipos, oficinas, compras, materiales o cualquier otro elemento que se necesiten
para llevar a cabo las actividades planificadas.
De esta manera al final de este proceso se habrá asignado a cada tarea los recursos
necesarios para su realización.
Este paso es importante porque cuando llegue el momento de presupuestar los costes
del proyecto, éstos se irán calculando, de abajo a arriba, como agregación del coste del
los recursos asignados a cada actividad, para calcular los costes de los paquetes de trabajo,
y así sucesivamente hasta llegar al coste del proyecto total.
Entre las actividades necesarias para lograr esta estimación de recursos están las
siguientes (Mulcahy, 2011):
• Revisar la disponibilidad de recursos.

• Revisar la EDT y la lista de actividades para ver el tipo de perfil de recurso
necesario.
• Revisar información histórica de otros proyectos que ayuden a estimar rendi-
mientos.
• Revisar las políticas de empresa relativas a la contratación o condiciones labo-
rales.
• Solicitar consejos de expertos sobre los recursos que se consideran más apro-
piados.
• Valorar si se realiza el trabajo internamente o se externaliza mediante un con-
trato.
• Cuantificar los recursos necesarios por cada actividad del nivel inferior.
• Crear una estructura jerárquica de los recursos necesarios por categoría y tipo.
• Desarrollar un plan sobre qué recursos, cómo y cuándo va a ser utilizados.
• Completar el análisis de las reservas de tiempo necesarias para el proyecto.
• Actualizar documentos anteriormente elaborados, si procede.

el grupo de procesos general:
En este esquema se ve con detalle el contenido del proceso:

En ISO21500 existe este mismo proceso con objetivos y resultados similares .También en
ISO21500 tiene como objetivo determinar los recursos necesarios –personal, equipamiento,
materiales, instalaciones...– para cada actividad.
Entradas Salidas
Lista de actividades Requisitos de recursos
Planes de proyecto Plan de Recursos
Cambios aprobados
ESTIMAR LOS RECURSOS DE LAS ACTIVIDADES (ESTIMATE

ACTIVITY RESOURCES)
Este proceso consiste en estimar el tipo y las cantidades de personas, materiales,
equipos o suministros requeridos para ejecutar cada actividad que posteriormente nos
ayudarán a estimar costes parciales y presupuesto total del proyecto.
ENTRADAS (INPUTS):
Para poder estimar bien los recursos necesarios se utilizarán el Plan de Dirección del
Proyecto (y especialmente el Plan de Gestión de Recursos y la Línea de base del alcance)
–donde se habrán definido el nivel de precisión de la estimación y las unidades de medida
de los recursos a estimar–, los documentos de proyecto (la lista de actividades y sus
atributos, el calendario de recursos –que recogerá la disponibilidad de los recursos nece-
sarios–, el registro de riesgos –que pueden afectar a la disponibilidad y selección de los
recursos–, las estimaciones de coste de las actividades –que pueden afectar en la selección
de los recursos–,…) y los factores ambientales de la empresa como la disponibilidad y
habilidades de los recursos y los activos de los procesos de la organización –políticas y
procesos en la asignación de recursos, en la contratación de bienes y servicios...– o
información histórica como fichas de estimación de recursos para cada actividad o
paquete de trabajo procedentes de proyectos anteriores.
Plan de Dirección del Proyecto (Project management plan)

Especialmente el plan de gestión de recursos, la línea de base del alcance así como
el Plan de Gestión del Cronograma que definirá cuáles son las unidades de medida y el
grado de detalle de las estimaciones así como, en caso de existir, las instrucciones para
adaptar los datos estadísticos de proyectos anteriores al proyecto concreto.

Creada anteriormente, indica las actividades necesarias para completar el proyecto
y a las que hay que asignar recursos.

Describen con más detalle las actividades y se hace una primera estimación del tipo
de recursos necesarios. Son la entrada principal para la estimación de recursos.
El registro de supuestos (Assumption log)

En él se recogerán los supuestos utilizados en las estimaciones (suponemos un ren-
dimiento de las personas, una capacidad de las instalaciones, una disponibilidad de unos
equipos,…)
Estimaciones de costes (Cost estimates)

El coste de los recursos de la compañía puede condicionar la selección de los mismos
y el análisis de alternativas para llevar a cabo determinados trabajos. Si, por ejemplo, el
proyecto no tiene una gran dificultad técnica pero su margen es pequeño, se tratará de
buscar perfiles junior que, siendo más baratos, puedan realizar los trabajos con garantías.
Calendario de recursos (Resource calendars)

Dará información sobre los recursos que pueden asignarse al proyecto. Antes de
comenzar un proyecto se necesitarán datos sobre los recursos disponibles y en qué fecha
estarán disponibles teniendo en cuenta, además, la experiencia o nivel de habilidad de
cada uno o su ubicación geográfica. En este proceso la comunicación fluida y franca
entre el responsable del proyecto y el responsable de los recursos –el director funcional,
normalmente– será crítica pues los recursos son responsabilidad del director funcional
o departamental mientras que la responsabilidad del proyecto es del project manager.
En caso de utilizar recursos externos como expertos, empresas consultoras, asisten-
cias técnicas…, se deberán planificar con antelación para que estén disponibles en las
fechas deseadas y después de haber formalizado todos los procesos de contratación que
son objeto del área de conocimiento «gestión de las adquisiciones del proyecto», que se
verá en el apartado correspondiente.
En el registro de riesgos pueden haberse recogido riesgos asociados con la disponi-
bilidad de recursos críticos para el proyecto.

Los factores más importantes son la disponibilidad y capacitación de los recursos
disponibles. Informarán de la manera en que los recursos humanos se asignan en la
empresa, los procedimientos de asignación de prioridades dentro de la cartera de pro-
yectos o la estructura de la organización. El project manager tendrá mayores o menores
facilidades para seleccionar los recursos según la empresa tenga una estructura jerárquica,
enfocada a proyectos o matricial.

Se incluirá tanto el conocimiento acumulado de otros proyectos –de gran ayuda
para estimar los recursos a asignar (entre ellos los datos de rendimiento del equipo)–
como políticas y procedimientos relativos a los recursos humanos o a la adquisición y
alquiler de suministros.
Con toda esta información, el project manager recogerá el juicio experto, el com-
promiso de las personas que han ejecutado o van a ejecutar esos entregables y la infor-
mación histórica de la organización, analizará las diferentes formas de ejecutar el trabajo,
estimará los recursos necesarios y los incorporará al sistema de información y herramienta
definidos por la organización que permita consolidarlos por paquetes de trabajo y cuen-
tas de control.

Como ocurría en procesos anteriores es una técnica que por inmediata no deja de
ser muy importante y a veces se olvida. Preguntar a quienes mejor conocen las activi-
dades a realizar, a quienes las han realizado anteriormente, a quienes las han supervi-
sado… dará información muy valiosa.
Por ejemplo, el project manager de la construcción de un nuevo puente puede
preguntar a los expertos en estructuras sobre las alternativas y la mejor manera de abordar
el proyecto desde el punto de vista de recursos y valorar la necesidad de subcontratar
aspectos especiales de la obra.
Estimación ascendente (Bottom-up estimation)

Los recursos se estiman al nivel de actividad y luego se agregan al nível de paquetes
de trabajo, entregables, ... Con una adecuada definición de actividades, se podrá hacer
una cuantificación y asignación de recursos fiable que permita conocer los recursos
totales necesarios por actividad. Con la agregación de los recursos y costes asignados a
las actividades se calculará los de los paquetes de trabajo y así, por agregaciones sucesivas,
se llegará a las necesidades de recursos para todo el proyecto distribuidas en el tiempo.
En el ejemplo de la construcción del puente, una vez se tiene bien estudiado el
proceso constructivo y bien identificadas las actividades y sus recursos se integrarán los
recursos internos y externos requeridos para actividad que conforman cada paquete de
trabajo hasta obtener los recursos totales necesarios para su obra, distribuidos a lo largo
de la vida del proyecto.
Estimación análoga (Analogous estimation)

Utiliza datos de recursos de proyectos previos como base para estimar los recursos
de futuros proyectos. Se usa como un método rápido muy especialmente cuando el PM
solamente puede identificar entregables del nivel más alto.
Estimación paramétrica (Parametric estimation)

Utiliza un algoritmo o una relación estadística entre datos históricos y otras variables
para estimar los recursos necesarios en los futuros proyectos. El nivel de detalle logrado
dependerá de los datos de partida y de la solidez del modelo estadístico

Una de las opciones de análisis son los análisis de alternativas. Cada project manager
llegará con alta probabilidad a una solución diferente. Por ello el project manager debe
tratar de buscar soluciones alternativas que le permitan optimizar recursos, adelantar
plazos, reducir riesgos... Del grupo de alternativas analizadas, elegirá la más adecuada al
proyecto.
Siguiendo con el ejemplo anterior, el project manager tendrá varias alternativas de
organización de la obra y de soluciones técnicas viables que deberá analizar y comparar
para decantarse por la que mejor se alinea con los objetivos del proyecto y las restric-
ciones impuestas. Cada alternativa tendrá un uso más o menos intensivo de maquinaria,
personal, equipos…
Sistemas de información para dirección de proyectos (PMIS)

Los programas más habituales del mercado tienen funcionalidades que permiten
asignar recursos, introducir restricciones (calendarios y horarios laborales, rendimien-
tos…), nivelar recursos de manera que se pueda elegir la solución óptima para el pro-
yecto, y mostrar los recursos y sus costes asociados en el tiempo. Permiten almacenar
información de proyectos anteriores y en ejecución organizar la asignación de recursos,
…
SALIDAS (OUTPUTS):
El resultado incluirá, por una parte, los recursos necesarios para cada actividad que
se podrán ir agregando, mediante estimación ascendente, para cada paquete de trabajo
y/o fase de proyecto, la documentación que recoja los datos utilizados, las hipótesis de
partida y la forma en que se ejecutó la estimación y, por último, la estructura de desglose
de recursos, una representación jerárquica de los recursos por categoría y tipo. Esta
información servirá de base, entre otros, a los procesos de estimar la duración de las
actividades, elaborar el cronograma, elaborar el Plan de Recursos y elaborar el plan de
gestión de adquisiciones.
Requisitos de Recursos de las actividades (Activity resources requirements)

Identifica, por actividad, los recursos necesarios para ejecutarla. Agregándolos, dan
los recursos necesarios para cada paquete de trabajo. El detalle dependerá del proyecto,
de la complejidad de las tareas, de la inmediatez y cantidad de datos de que se disponga.
Bases de las estimaciones (Basis of estimates)

Sí será muy importante documentar las hipótesis y supuestos a la hora de estimar
esas necesidades de recursos (qué rendimientos, qué perfil de personal se ha considerado,
disponibilidad y cantidad) porque el proyecto puede ser largo –y convenga refrescar las
hipótesis de partida– o porque pueda retomarlo otro project manager y, al revisar el
estado del proyecto y hacer un primer análisis de riesgos, necesita tener esa información
disponible.
Esta salida será entrada para los procesos de:
• «Estimar la duración de las actividades» y «Elaborar el Cronograma» correspon-
dientes al área de conocimiento de gestión del tiempo.
• «Planificar la gestión de los recursos humanos» del área de conocimiento de
gestión de recursos humanos.
Estructura de desglose de recursos (Resource breakdown structure)

Es una estructura jerárquica de los recursos por categorías (mano de obra, material,
equipos, suministros…) y tipos de recursos (experiencia, formación, capacidades…) y
se utilizará para organizar y comunicar los datos del cronograma del proyecto así como
la utilización prevista de recursos.
Esta salida será entrada para los procesos de «Estimar la duración de las actividades»
y «Elaborar el Cronograma» correspondientes al área de conocimiento de gestión del

tiempo.

Como ocurre en todos los procesos que estamos viendo dentro del grupo de pla-
nificación, y veremos en el de seguimiento y control, conforme se avanza en la defini-
ción del proyecto se requiere actualizar documentos anteriormente elaborados para
introducir nuevos aspectos que puedan ser relevantes para el buen desarrollo del pro-
yecto. Documentos como la lista de actividades, sus atributos y el calendario de recursos
se actualizarán tras este proceso
3.9. PLANIFICAR LAS COMUNICACIONES DE PROYECTO
Una vez definido el Plan de Gestión de los Interesados, los Planes de Gestión del
Alcance, Tiempo, Coste y Calidad, y el Plan de Gestión de Recursos Humanos ya se
puede definir con el detalle necesario el Plan de Comunicaciones del proyecto.
Este proceso trata de desarrollar y planificar una forma adecuada de comunicaciones
del proyecto teniendo en cuenta las necesidades y requisitos de información de los
interesados. Permite documentar la forma de comunicarse de la forma más efectiva y
eficiente con las partes interesadas.
Estas consideraciones son muy importantes para el éxito final del proyecto. Una
planificación inadecuada de las comunicaciones puede llevar a problemas como retrasos
en la transmisión de un mensaje, comunicar información a las personas equivocadas,
informar insuficientemente a las partes interesadas y mala comprensión o interpretación
equivocada del mensaje comunicado.
La comunicación efectiva significa que se da la información en el formato adecuado,
en el momento adecuado, a las personas adecuadas y obteniendo el impacto previsto.
La comunicación eficiente, por su parte, significa dar únicamente la información nece-
saria.
Entre las consideraciones que hay que tener en cuenta están:
• quién necesita qué información,
• quién está autorizado a acceder a esa información,
• cuándo necesitarán esa información,
• dónde debe almacenarse la información,
• en qué formato debe almacenarse la información,
• si es necesario tener en cuenta barreras culturales o de lenguaje...
Los resultados del proceso de planificar la gestión de las comunicaciones deben
revisarse regularmente a lo largo de la vida del proyecto y actualizado cuando sea nece-
sario para asegurar su validez.
En este esquema se ubica el proceso de planificar la gestión de las comunicaciones

dentro de su área de conocimiento y las cinco fases del proyecto:
Todo ello se recoge en el Plan de Comunicación que, junto a otros, será un plan
subsidiario del Plan de Dirección del Proyecto y cuya elaboración sigue el siguiente
proceso:
Planificar las comunicaciones de proyecto 335
En ISO21500 existe un proceso similar, Planificar las Comunicaciones, cuyo objetivo es

determinar las necesidades de información y comunicación de las diferentes partes interesadas.
Las comunicaciones adecuadas son un factor de éxito del proyecto si se tienen en cuenta
tanto las necesidades de información de las partes interesadas y se definen los medios adecuados
para hacérsela llegar.
Este proceso comienza nada más empezar el proyecto, con la identificación de las partes
interesadas, pero debe ser revisado y actualizado regularmente para garantizar su efectividad
durante toda la vida del proyecto.
Entradas Salidas
Planes de proyecto
Registro de partes interesadas Plan de Comunicaciones
Descripciones de roles
Cambios aprobados
PLANIFICAR LA GESTIÓN DE LAS COMUNICACIONES (PLAN

COMMUNICATION MANAGEMENT)
Se determinan las necesidades de información de todos los interesados del pro-
yecto, qué debe saber quién, en qué momento y de qué manera se le informará.
Define cómo abordar las comunicaciones entre todas las partes interesadas definiendo
flujos y medios de distribución de la información.
ENTRADAS (INPUTS):
Entre la información a tener en cuenta para elaborar el Plan de Gestión de las

Comunicaciones de proyecto están el Plan de Dirección del Proyecto, los factores
ambientales de la empresa –que pueden condicionar el contenido y cauces de la comu-
nicación– y los activos de los procesos de la organización –entre ellos, las lecciones
aprendidas e información histórica relativa a decisiones tomadas en relación a temas de
comunicación y el resultado de esas decisiones en proyectos similares– que pueden
utilizarse como guía para planificar las actividades de comunicación del proyecto actual.
Acta de constitución del proyecto (Project Charter)

En el acta de constitución del proyecto es donde se identifica la lista principal de
interesados, conteniendo además información acerca de sus roles y responsabilidades.

En el Plan de Dirección del Proyecto se recoge cómo se va a ejecutar, monitorizar,
controlar y cerrar el proyecto, información que deberá tenerse en cuenta a la hora de
elaborar el Plan de Gestión de las Comunicaciones, de tal manera que la comunicación
sea soporte y elemento facilitador de la gestión del proyecto.

Principalmente, el registro de interesados donde se recoge información relevante
sobre los interesados que será de utilidad a la hora de definir y planificar las comunica-
ciones con cada uno de ellos, y la documentación de requisitos, ya que puede incluir
requisitos con respecto a la comunicación de los interesados

Se centrará en el análisis en la cultura de la compañía en relación a la comunicación
en los proyectos y dentro de la propia organización que podrá ser más o menos formal,
más o menos flexible, con unas tecnologías o con otras… De igual manera habrá que
tener en cuenta la estructura organizativa y cómo están establecidos los flujos de reporte
y escalado de información, problemas y decisiones.

Recoge el conocimiento adquirido por la empresa y recogido en plantillas, proce-
dimientos, procesos e instrucciones relativos en este caso a la comunicación entre los
empleados, departamentos y niveles jerárquicos.
También recogerá experiencias sobre decisiones acertadas o equivocadas tomadas
en proyectos anteriores y sus resultados. Si algo no funcionó bien en el pasado y generó
problemas de comunicación y conflictos entre partes interesadas conviene conocerlo al
inicio de la elaboración del Plan de gestión de las Comunicaciones del nuevo proyecto.
Juicio de expertos
La experiencia de individuos o grupos con un conocimiento o formación especia-
lizada en el tema que estamos planificando es una herramienta común a todos los pro-
cesos de planificación.
Análisis de requerimientos de comunicación (Communications requirements

analysis)
El análisis de los requerimientos de comunicación determina las necesidades de
información de las partes interesadas. Estos requerimientos se definen combinando el
tipo y formato de la información necesaria con un análisis del valor de dicha informa-
ción. Los recursos del proyecto deben emplearse únicamente en comunicar la infor-
mación que es relevante y que contribuye al éxito del proyecto o donde una falta de
esa comunicación puede llevar a errores que conlleven el fracaso del proyecto.
Este análisis permitirá determinar las necesidades de información de los interesados
–contenido, tipo y formato de la información–.
El project manager debe identificar la información que realmente necesita cada parte
interesada para estar informada del proyecto y de los aspectos que le afectan expresa-
mente y poder tomar las decisiones que mejor le convengan. El project manager evitará
saturarles de información no relevante ya que, de esa manera, se complicará su análisis
y toma de decisiones.
Por ello, en esta fase, el project manager, con la información que haya obtenido
sobre las necesidades y expectativas de los interesados, debe identificar la información
realmente necesaria, cuándo deben tenerla y la mejor manera de hacérsela llegar.
El project manager tiene que pensar bien el número de partes interesadas que van
a recibir la información ya que, como se ve a continuación, el aumento del número de
partes interesadas aumenta mucho los pares de comunicación. El número de partes

interesadas en el proyecto hace cada vez más complejo el sistema de distribución de la
información como se puede deducir de la fórmula (N(N-1))/2 que calcula el número
de canales de comunicación en función de N, número de personas u organizaciones. Si
tenemos 5 partes interesadas el número de canales de comunicación será:
5 (5 - 1) / 2 = 10
Y si añadimos dos nuevas partes interesadas el número de canales subirá a
7 (7 - 1) / 2 = 21
Lo que nos indica que aumentar un 40% el número de personas u organizaciones
como partes interesadas, aumentará en un 110% el número de canales pasando de 10 a
21. Por ello, conviene tratar de reducir N buscando personas que hagan de represen-
tantes de grupos homogéneos de intereses.
El PMBOK® propone varias fuentes para recoger esta información:
• los organigramas de los departamentos y la compañía,

• las relaciones de responsabilidad de las partes interesadas, otras unidades y depar-
tamentos implicados en el proyecto,
• los recursos asignados al proyecto y su ubicación física en relación al lugar de
realización y coordinación de las actividades,
• las necesidades internas de información que tenga la organización sobre el pro-
yecto (avance, costes, plazos, calidad, riesgos…) para el seguimiento del pro-
yecto,
• las necesidades externas de información para proyectos con repercusión social
(prensa, administraciones públicas…), o
• la propia información sobre las partes interesadas.
Tecnología de las comunicaciones (Communications technology)

Las nuevas tecnologías de comunicación (correos electrónicos, sitios web o ftp,
videoconferencias…) facilitan la distribución de la información de manera más rápida y
eficiente. El nivel del tecnología disponible para el proyecto condicionará la comuni-
cación (contenido, periodicidad, asistencia…) de sus participantes.
La selección de la tecnología dependerá de varios factores como:
• El plazo para la distribución de la información y su periodicidad.
• La rapidez con que se requiere la respuesta.
• La disponibilidad de tecnologías avanzadas (sala de videoconferencias…).
• La experiencia de los participantes con estas tecnologías.
• La duración del proyecto, que haga que pueda cambiar la tecnología y no dé
tiempo a implantarla.
• El entorno cultural que puede priorizar el trabajo cara a cara.
• La ubicación del equipo, ya en un mismo lugar, ya en diferentes edificios, ciu-
dades o países.
• El grado de sensibilidad y confidencialidad de la información.
Modelos de comunicación (Communication models)

Son teorías desarrolladas por los especialistas en comunicación, que no son objeto
de estudio en este documento. Sin embargo, un buen project manager las deberá tener
en cuenta ya que los mensajes que enviamos sufren un doble proceso de codificación y
descodificación en entornos no siempre ideales –diferente idioma, nivel de atención…–
y que pueden distorsionar el mensaje inicial. Incluso una misma palabra para dos personas
del equipo que hablan el mismo idioma puede tener diferente significado.
De acuerdo a PMBOK® un modelo de comunicación tiene los elementos reflejados
en el esquema siguiente donde:
• La codificación es poner en palabras o signos los pensamientos del emisor.
• El mensaje es el resultado de ese proceso.
• El medio es el lugar o método utilizado para la comunicación.
• El ruido es cualquier impedimento que encuentra el mensaje para llegar a su

destinatario de forma clara y nítida (diferente idioma, ruido físico, estado emo-
cional…).
• La decodificación es el proceso de traducción del mensaje escrito u oral a pen-
samientos y conclusiones por parte del receptor.
• La confirmación de recepción es la señal que emite el receptor de que el mensaje
ha sido recibido. Sin embargo, esto no indica que se ha comprendido o que se
esté de acuerdo con él.
• Feedback o mensaje de respuesta suele ser una buena herramienta a usar para
confirmar que el mensaje que hemos enviado ha sido comprendido adecuada-
mente.
El emisor es responsable de que la información que transmite sea tal que pueda ser
comprendida por el receptor mientras que es responsabilidad de éste confirmar que ha
recibido toda la información, ha sido correctamente entendida, confirmar que es así y

responder adecuadamente.
Otros elementos que pueden dificultar la buena comunicación, aparte de los mera-
mente físicos (ruido, distancia), son las afirmaciones categóricas, los tonos negativos, el
diferente idioma hablado, o el uso que se haga del idioma común, las diferencias cul-
turales, los prejuicios del receptor respecto al emisor…
Métodos de comunicación (Communication methods)

Se puede hablar de tres métodos básicos de comunicación:
• Método interactivo: todas las partes interesadas intercambian información entre
sí como en reuniones, videoconferencias, llamadas telefónicas…
• Tipo push: el project manager envía información a las partes interesadas vía
email, informes u otras formas de comunicación unidireccionales. Este método
envía el mensaje pero no se asegura de que haya llegado al receptor.
• Tipo pull: cuando las partes interesadas se descargan la información disponible

depositada, por ejemplo, en un servidor ftp.
Asegurarse que el destinatario ha recibido la información y la ha comprendido,
entendiendo lo que el emisor quería transmitir es una de las claves a tener en cuenta a
la hora de definir el modelo y método de comunicación por parte del project manager.
La escucha activa, la confirmación mediante retroalimentación para asegurarse que ha
comprendido el mensaje son técnicas, tan sencillas y críticas en un proyecto, como poco
utilizadas.
Habilidades interpersonales y de trabajo en equipo

Algunas de las habilidades interpersonales y de equipo a aplicar en este proceso serían
la identificación del estilo de comunicación (método, formato y contenido), la con-
ciencia política para planificar las comunicaciones en función del ambiente del proyecto
de la organización, y la conciencia cultural, adaptando la estrategia de comunicación al
entendimiento de las diferencias entre individuos, grupos y organizaciones.
Representación de datos
Representación de datos que ayuden a identificar requisitos adicionales de comu-
nicación. Por ejemplo, la matriz de evaluación de la participación de los interesados,
que muestra la distancia entre el grado de participación actual y el deseado.
El proceso de definición de cómo se van a definir las necesidades de comunicación,
cómo se van a gestionar y cómo se van a controlar, requiere reuniones con las partes
interesadas más relevantes del proyecto con el objetivo de recoger sus necesidades de
comunicación tanto en lo que a contenido se refiere como al momento y la forma. Será
clave saber para qué necesitan la información –realizar un trabajo, tomar una decisión,
dar su opinión, sentir un cierto control sobre el avance del proyecto...– con el objetivo
de mejor definir qué información realmente necesitan y no saturar con un exceso de
información.
SALIDAS (OUTPUTS):
Plan de Gestión de las Comunicaciones (Communication management plan)

Como resultado de este proceso se obtiene el Plan de Gestión de las Comunica-
ciones que describirá cómo se van a planificar, estructurar, monitorizar y controlar las
comunicaciones de proyecto.
Este plan deberá asegurarse de que todas las partes implicadas comprenden la razón
y objetivos de las reuniones, videoconferencias, avisos e informes que el project manager
envía. Por ello, será importante que todo envío lleve el objetivo y las razones que jus-
tifican el mismo.
Planificar la gestión de riesgos 341
Asimismo el plan indicará cómo distribuirá la información el project manager, a

quién y con qué frecuencia. En ocasiones el project manager indicará a alguna o algunas
de las partes interesadas que distribuyan la información a su vez a otro grupo de interés.
En este último caso se puede aumentar el riesgo de ruido, mala interpretación y difícil
retroalimentación con el project manager, deberá valorarse muy bien si no es posible y
deseable una comunicación directa.
La información transmitida puede tener que ver con cambios propuestos, eventos
de riesgo ocurridos, avances del alcance, retrasos en plazos…y en cada caso el modo,
tono y la forma de enviarlo serán diferentes.
PMBOK® considera que un Plan de Gestión de las Comunicaciones debe incluir
los siguientes elementos:
• Los requisitos de comunicación de los interesados y la información requerida.
• El motivo, plazo y frecuencia de esa información.
• Las personas responsables de autorizar la divulgación y de comunicar la infor-
mación.
• Las personas o grupos que recibirán la información y mediante qué métodos y
tecnologías.
• Los recursos asignados para las tareas de comunicación.
• La cadena de mando y el proceso de escalado para la elaboración, revisión,
aprobación y envío de la información y la información que puede llegar según
el nivel de mando.
• Las normas internas en materia de comunicación.
• Los procedimientos específicos de cambio para actualizar el plan.
El Plan de Gestión de las Comunicaciones será la entrada principal para el proceso
de «Gestionar las comunicaciones» y «Gestionar la implicación de los interesados»
correspondiente al grupo de procesos de ejecución.

Los documentos que pueden verse afectados como resultado de la planificación de
las comunicaciones son, entre otros, el registro de partes interesadas o el cronograma de
proyecto.
Actualización del plan de dirección de proyecto (Project Management Plan

updates)
Principalmente, el plan de participación de interesados que se actualizará para reflejar
cualquier proceso, procedimiento, herramienta o técnica que afecte a la participación
de los interesados en las decisiones y ejecución del proyecto.
3.10. PLANIFICAR LA GESTIÓN DE RIESGOS
Una vez ya elaborados los Planes Subsidiarios correspondientes a las partes intere-
sadas, alcance, tiempo, coste, calidad, recursos humanos y comunicaciones podemos
completar el Plan de Gestión de Riesgos con la identificación, evaluación y definición

de respuestas a los riesgos identificados en los planes anteriores.
Esta área de conocimiento incluye los procesos para llevar a cabo la planificación de
la gestión de riesgos, la identificación, análisis y planificación de la respuesta a los riesgos
y el control y monitorización de los riesgos de un proyecto. Sus objetivos son incre-
mentar la probabilidad y el impacto de eventos positivos (oportunidades) y reducir la
probabilidad e impacto de los eventos negativos (riesgos) en el proyecto.
Gestión de riesgos de un proyecto (Project risk management)

Incluso el proyecto mejor planificado puede tener problemas. Por muy bien que se
planifique un proyecto, siempre pueden producirse circunstancias inesperadas. Es inevi-
table que algún miembro del equipo se ponga enfermo, recursos que se esperaban no
estén disponibles o un proveedor falle en el peor momento posible. Pero eso no quiere
decir que, por ello, el project manager deba rendirse y esperar pacientemente a que
vayan llegando los problemas.
De hecho el principal trabajo de un project manager, y por lo que se valora, no es
por su capacidad para resolver problemas sino para prevenirlos. Y en buena medida, es
la razón de ser de la gestión de riesgos: anticiparse a los problemas, evitarlos y, si no es
posible, minimizarlos mediante un Plan de Respuesta.
Todo ello hará que el proyecto y la compañía ahorren tiempo y dinero. Esto último
puede parecer un contrasentido pero, cuando se eliminan las incertidumbres, las esti-
maciones del coste y del plazo se reducen produciéndose esos beneficios.
El project manager puede y debe utilizar procesos de gestión de los riesgos del
proyecto para identificar los riesgos potenciales que pueden aparecer y elaborar planes
de respuesta para esa eventualidad.
La gestión de riesgos en un proyecto incluye:
• La planificación de cómo se van a gestionar los riesgos.
• La identificación de riesgos.
• El análisis cualitativo y, en los más relevantes, cuantitativo.
• La definición de planes de respuesta para los riesgos residuales (aquellos que no
se hayan podido eliminar desde un primer momento).
• La supervisión y control durante la ejecución del proyecto de que:
– no aparecen nuevos riesgos,
– algunos pierden relevancia al reducirse su probabilidad o impacto, o
– se vuelven más probables o con mayor impacto,
– se revisan los indicadores de aviso,
– se ponen en marcha los planes de respuesta en cuanto sea necesario,
– se informa en todo momento a las partes interesadas.
• Reiniciar el proceso de re-evaluación si procede (por aparición de nuevos ries-
gos…) en un proceso iterativo que hará que el project manager mantenga esa
actitud proactiva que le debe caracterizar en todas sus actuaciones (mirar al
futuro identificando problemas y no dejar que lleguen para resolverlos).
Riesgos (Risks)
Un riesgo en un proyecto es:
• Un evento incierto (uncertain event): no hay suficiente información para ase-
gurar su aparición y su impacto que puede afectar al coste, duración, calidad…
del proyecto.
• Una condición que, de producirse, tiene un efecto positivo (al que podemos
llamar oportunidad) o negativo (al que podemos llamar amenaza) en los obje-
tivos de un proyecto, ya sea en el plazo, en el coste, en el alcance, la calidad…
Siempre que haya algo que pueda ocurrir en el proyecto y cambiar el desarrollo y
el resultado previsto del mismo lo llamaremos riesgo u oportunidad (dependiendo el
signo del impacto en los objetivos del proyecto).
Las causas del riesgo pueden ser:
• Un evento (una tormenta que impide que el transporte marítimo pueda llegar
a tiempo con los equipos solicitados).
• Un requisito (tener o no lista la licencia de obras para comenzar los trabajos).
• Un supuesto o hipótesis (poder contar o no con dos programadores senior).
• Una restricción impuesta a posteriori (el montaje de torres puede afectar o no al
tráfico en la zona).
Los eventos de riesgo serán, para cada caso:
• La tormenta que retrasa la llegada de los equipos solicitados.
• El retraso por parte del Ayuntamiento en dar el visto bueno y entregar la licencia
de obras que retrasa los trabajos.
• No poder contar con uno de los programadores que puede llevar a retrasos,
contratación de un programador junior que puede afectar al tiempo y a la cali-
dad.
• La propia restricción obliga a tener prevista una grúa más ligera, a tener pro-
blemas con los vehículos reduciendo la velocidad de montaje, un mayor impacto

en caso de accidente.
Sin embargo no todos los riesgos son negativos. Algunos eventos (la aparición de
una nueva tecnología que simplifique alguna de nuestras actividades) o condiciones (la
bajada de precios de una materia prima) pueden ayudar a nuestro proyecto. En estos
casos los llamaremos oportunidad.
Si bien riesgos habrá siempre, podemos distinguir entre:
• Riesgos conocidos (known unknowns), identificados y analizados, y para los
que hay una respuesta.
• Riesgos desconocidos (unknown unknowns), que no pueden planificarse con
antelación y para los que únicamente cabe crear una reserva de gestión (o reserva
gerencial).
Los eventos que se sabe que van a ocurrir (known knowns) no son riesgos, son
problemas a resolver con acciones que estarán recogidas en el alcance del proyecto con
su duración y su coste estimado.
Los factores de un riesgo (risks factors) son tres:
• Un evento que puede ser definido (event): un terremoto, la quiebra de un pro-
veedor…
• La probabilidad (probability) de que ocurra.
• El impacto (impact) o consecuencias sobre los objetivos del proyecto en caso
de que ocurra.
Otros aspectos a tener en cuenta a la hora de caracterizar los riesgos son:
• El momento esperado de ocurrencia en la vida del proyecto (expected timing).
• El tiempo necesario para poder actuar sobre él (time response).
• La frecuencia anticipada de la ocurrencia de eventos con la misma causa.
Por último, interesa definir dos conceptos relativos a los riesgos como son:
• La tolerancia al riesgo (risk tolerance): áreas en que son aceptables o inaceptables
(un riesgo que puede producir un retraso no es aceptable en una obra emble-
mática que tiene cita de inauguración).
• Umbral de tolerancia (risk threshold): nivel del impacto de los riesgos que es
aceptable (en el ejemplo anterior, por ejemplo «un riesgo que produzca un
retraso no superior a una semana es aceptable siempre que se conozca con un
mes de antelación»).
En ambos casos es la alta dirección quien debe definir y fijar estos parámetros y
recogerlos dentro de sus activos de procesos y factores ambientales de la organización.
Responsabilidades en la gestión de los riesgos

El project manager es el principal responsable de planificar y gestionar los riesgos:
• Iniciando y liderando el proceso de gestión de los riesgos del proyecto.

• Buscando el apoyo y la experiencia de las partes interesadas a la hora de iden-
tificarlos, priorizarlos y buscar las respuestas más adecuadas.
• Dando directrices al equipo del proyecto en referencia a los procesos y herra-
mientas a utilizar en la gestión de los riesgos del proyecto.
La identificación, cuantificación y priorización, así como la aprobación final del
plan, se realiza de forma conjunta entre el project manager, el equipo, los stakeholders
y el cliente.
Por su parte el equipo de proyecto debe:
• Entender y seguir el proceso de gestión de los riesgos del proyecto.
• Ejecutar las estrategias de gestión de los riesgos del proyecto.
• Comunicar el estado del proceso de gestión de los riesgos del proyecto.
Planificación de riesgos en el proceso de planificación del proyecto

El análisis de riesgos no es algo estático que se realiza al inicio del proceso de pla-
nificación y luego se abandona. Durante toda la fase de planificación la identificación y
el análisis de riesgos son actividades de un proceso que debe mantenerse vivo e ir com-
plementándose y actualizándose.
Los datos de entrada necesarios para una adecuada planificación de riesgos se pueden
obtener de:
• Información histórica de proyectos anteriores y lecciones aprendidas.
• Políticas, procedimientos, procesos y cultura de la empresa (entre ellas la tole-
rancia al riesgo).
• Información previa al inicio del proyecto y a la decisión de ser aprobado.
• Información ya elaborada del proyecto y que describe los objetivos, alcance,
presupuestos y plazos estimados como:
– el Acta de Constitución (project charter),
– el Enunciado del Alcance del Trabajo (project scope statement),
– la Estructura de Desglose de Trabajos, EDT (Work Breakdown Structure,
WBS),
– los diagramas de red (Network Diagram),
– las estimaciones de tiempos y costes (cost and time estimates), u
– otros planes como el de comunicación, el de compras, el de recursos
humanos.
• Lista de partes interesadas.
Pero no solamente en la fase de planificación sino también en la de ejecución,
seguimiento y control y cierre del proyecto, la gestión de los riesgos del proyecto (pro-
ject risk management) es una responsabilidad que el project manager debe tener muy
presente:
• de forma periódica a través del ciclo de vida de proyecto,

• cada vez que un nuevo plan o línea de base se establezca,
• cada vez que se produzca un cambio y se apruebe su implantación en hitos
relevantes (milestones) o
• momentos que requieren una decisión (decision or kill points).
El seguimiento y control de riesgos se realiza continuamente a través del Ciclo de
vida del proyecto y durante las actualizaciones de estado y reporte del proyecto.
Tipos de riesgos
Los riesgos se pueden clasificar en función de:
• Sus componentes: probabilidad de ocurrencia e impacto de la ocurrencia.
• Si se originan de fuentes internas o externas.
• Si son riesgos de negocio (los normales con potencial de hacer ganar o perder)
o los puros o asegurables (que presentan solo potencial de pérdidas).
Procesos del área de conocimiento gestión de los riesgos del proyecto

En el esquema siguiente se observa el grupo de procesos relacionados con la plani-
ficación y gestión de los riesgos del proyecto (project risk management):
Como se comentó en el primer capítulo existen algunas diferencias entre ISO21500

y PMBOK en lo que a esta área de conocimiento se refiere y que se presentan en la

siguiente tabla en la que, en cursiva, se presentan los procesos de ISO21500:
Cie-
Inicio Planificación Ejecución Control
rre
Planificar la gestión de riesgos
Identificar los riesgos
Realizar el análisis cualitativo de ries- Controlar los
gos riesgos
Realizar el análisis cuantitativo de (Tratar los riesgos) (Controlar los ries-
riesgos gos)
Planificar la respuesta a los riesgos
(Identificar riesgos)
(Evaluar los riesgos)
La gestión de los riesgos del proyecto implica planificar la gestión de riesgos, iden-
tificarlos, analizarlos, definir planes de respuesta a los riesgos y realizar un seguimiento
y control de los riesgos, para aumentar la probabilidad e impacto de los eventos positivos
y disminuir la probabilidad e impacto de los eventos negativos para el proyecto:
En la siguiente tabla se presentan los procesos de gestión de riesgos (y su composición
con las de ISO21500):
Se define, teniendo en cuenta el marco y estrategia de gestión

de riesgos de la organización, cómo se van a identificar, plani-
ficar, gestionar, monitorizar y controlar los riesgos y oportuni-
Planificar la Gestión de dades del proyecto.
Riesgos (Plan risk manage-
ment) Este proceso no se recoge en ISO21500 si bien se considera que se
elabora como parte del Plan de Dirección del Proyecto y sus Planes
Subsidiarios.
Proceso mediante el cual se determinan qué riesgos y oportu-

nidades pueden afectar al proyecto y documentar sus caracte-
Identificar los riesgos rísticas.
(Identify risks)
Este proceso no se diferencia del que recoge la ISO21500.
Proceso mediante el cual se priorizan los riesgos mediante la

evaluación conjunta de su probabilidad e impacto con el obje-
tivo de identificar aquellos que requerirán un análisis más deta-
Realizar el análisis cualita- llado.
tivo de riesgos (Perform ISO21500 recoge el proceso «Evaluar riesgos» cuyo objetivo es medir
qualitative risk analysis) y priorizar los riesgos identificados. Por tanto, recogería los objetivos y
contenidos de los procesos «Realizar el análisis cualitativo de riesgos»
y «Realizar el análisis cuantitativo» de riesgos de PMBOK.
Proceso mediante el cual se analiza el impacto numérico del

efecto de los riesgos identificados como más relevantes en los
Realizar el análisis cuantita- objetivos del proyecto.
tivo de riesgos (Perform Como se ha indicado ISO21500 recoge en el proceso «Evaluar riesgos»
quantitative risk analysis) los objetivos y contenidos de los procesos «Realizar el análisis cualitativo
de riesgos» y «Realizar el análisis cuantitativo» de riesgos de PMBOK.
Proceso mediante el cual se estudian opciones y se definen

acciones para aumentar la probabilidad e impacto de las opor-
tunidades y reducir la probabilidad e impacto de los riesgos.
Planificar la respuesta a los El proceso «Tratar los riesgos» de ISo21500 recoge los objetivos y
riesgos contenidos del proceso «Planificar la respuesta a los riesgos» de
(Plan risks response) PMBOK sin diferencias significativas, salvo el hecho de que en
ISO21500 el proceso forma parte del grupo de procesos de ejecución y
en PMBOK del grupo de procesos de Ejecución.
Proceso mediante el cual se asegura que los planes de respuesta

a riesgos aprobados se llevan a cabo dentro del proyecto
Implementar respuestas a
los riesgos El proceso «Tratar los riesgos» de ISO21500 recoge los objetivos y
(Implement risks responses) contenidos del proceso «Implementar la respuesta a los riesgos» de
PMBOK 6.ª Edición sin diferencias significativas.
Proceso mediante el cual se supervisa el estado de los riegos

identificados y el resultado obtenido tras la ejecución de los
planes de respuesta a los riesgos.
Monitorizar los riesgos
(Monitor risks) El proceso Controlar riesgos de ISO21500 recoge los objetivos y con-
tenidos que el proceso del mismo nombre de PMBOK 6.ª Edición
Aunque los procesos que componen el área de gestión de riesgos se presenten

secuenciados, esta gestión se prolonga durante todo el proyecto. Un riesgo puede
detectarse en cualquier momento y sea cual sea ese momento, éste deberá seguir el
proceso completo (análisis, evaluación, priorización y selección y planificación, si pro-
cede, de la respuesta más adecuada). Además, estos procesos interactúan entre sí y con
los correspondientes a otras áreas de conocimiento.
Debido a la importancia del orden y relaciones a seguir en este proceso de gestión
de riesgos se presenta el siguiente esquema que muestra el flujo de gestión de riesgos
completo con sus interrelaciones que serán analizadas en los sucesivos puntos. Este
esquema es similar al anterior pero desglosado en actividades más concretas y marcando
de forma más clara las relaciones entre ellas, y será de gran ayuda a la hora de abordar
la planificación y gestión de riesgos en un proyecto:
3.10.1. Planificar la gestión de riesgos

Este proceso tiene por objetivo definir cómo se van a llevar a cabo las actividades
de gestión de riesgos de un proyecto y asegurar que el grado, tipo y visibilidad de la
gestión de riesgos sea adecuada a los riesgos e importancia del proyecto para la organi-
zación. Una planificación explícita y detallada aumentará la probabilidad de éxito del
resto de procesos de esta área. Y esta planificación debe comenzar al inicio del proyecto
y la elaboración del Acta de Constitución.
Este proceso, que deberá iniciarse tan pronto como se inicie la concepción del pro-
yecto, define cómo planificar para luego gestionar los riesgos del proyecto, concretando
los recursos y el tiempo necesario para las actividades enfocadas a la gestión de los riesgos
del proyecto y establecer unos criterios acordados para evaluarlos.
El project manager define cómo gestionar este área siendo consciente de que los
recursos y esfuerzos a dedicar dependerán del tamaño y complejidad del proyecto, así
como de la experiencia del equipo de proyecto y la compañía en proyectos similares.
Deberá, por tanto, cuantificar el esfuerzo en actividades de planificación, segui-
miento y control y ejecución de planes de respuesta que un proyecto concreto necesita.
De esta manera, una vez definido el Plan de Respuestas deberá incluir las actividades
que requiere en la EDT y actualizar los planes de gestión del alcance, del cronograma,
del presupuesto y de la calidad del proyecto, en un proceso iterativo representado en el
esquema anterior.
El siguiente esquema ubica el proceso de planificación de la gestión de los riesgos
del proyecto dentro de su área de conocimiento, y su grupo de procesos dentro del
proyecto:
En el esquema siguiente se sintetiza el proceso de elaboración del Plan de Gestión

de los riesgos del proyecto que pasaremos a desarrollar a continuación:
En ISO21500 no existe un proceso similar aunque se sobreentiende que se encuentra

dentro del proceso de «Elaborar los planes de proyecto», uno de los cuales es el Plan de Gestión
de Riesgos.
PLANIFICAR LA GESTIÓN DE RIESGOS (PLAN RISK MANAGE-

MENT)
El objetivo final es decidir cómo enfocar, planificar y ejecutar las actividades de
gestión de los riesgos del proyecto para un proyecto. El momento en el que un riesgo
aparece es ya tarde. En ese momento ya no es un riesgo, es un problema y tenemos
que buscarle una solución rápida y efectiva. Esta es la razón por la que se necesita
planificar los riesgos desde el inicio –para anticipar su aparición– y mantener una
supervisión durante la fase de ejecución del proyecto –que permita identificar indicios
de que aparecen o pueden aparecer otros no previstos–.
ENTRADAS (INPUTS):
Entre la información necesaria está el Plan de Dirección del Proyecto –que recoge
todos los Planes Subsidiarios y líneas de base que deben tenerse en cuenta al realizar el
Plan de Gestión de Riesgos–, el Acta de Constitución –en la que se recogen los riesgos
y requerimientos de alto nivel así como una primera descripción del proyecto–, el
registro de partes interesadas –con información de las mismas, sus necesidades, sus
roles…, a tener en cuenta en la planificación de la gestión de riesgos–, los factores
ambientales de la empresa –actitudes y tolerancia ante el riesgo de la organización– y
los activos de los procesos de la organización –mapa y categorías de riesgos, plantillas,
roles y responsabilidades, niveles de autoridad, lecciones aprendidas…–.
Acta de Constitución (Project Charter)
En el Acta de Constitución se recogen los riesgos de alto nivel asociados al proyecto
así como las hipótesis y restricciones de proyecto y requerimientos de alto nivel. Todos
ellos habrá que tenerlos en cuenta a la hora de identificar posibles riesgos.
Conviene tener en cuenta la siguiente información a la hora de planificar los riesgos:
El project manager no puede identificar riesgos solo. El proceso de

Equipo de proyecto identificar riesgos será más preciso con el enfoque que aporte un
(Project team)
equipo.
Partes interesadas Que ayudarán a detectar riesgos, por lo que su implicación es parte
(Stakeholders) importante de una apropiada gestión de los interesados.
Plan de Gestión de
Costes Que define la forma en que se informarán y utilizarán los presupuestos
(Cost management para la cobertura de riesgos, las contingencias y las reservas de gestión.
plan)
Plan de Gestión del
Cronograma (Sche- Que define la forma en que se informarán y evaluarán las contingen-
dule management cias del cronograma y las reservas de tiempo.
plan)
Plan de Gestión de las
Comunicaciones Que determina quién será responsable de distribuir a quién corres-
(Communication ponda la información sobre los diversos riesgos y sus respuestas.
management plan)
Una vez definida, normalmente a nivel de alta dirección y dentro del
Tolerancia al riesgo
plan estratégico, permite conocer en qué áreas y qué nivel de tole-
(risk tolerance) de las
rancia tienen los interesados. Ayuda a identificar el impacto del riesgo
partes interesadas
y qué técnica de mitigación del riesgo debe aplicarse.
Estructura de des- Los riesgos se identifican para cada tarea, para grupos de tareas (con
glose de tareas una causa raíz común y una solución conjunta) o a totalidad del pro-
(Work breakdown
structure) yecto (pudiendo lograrse sinergias).
El camino crítico y los cuasi-caminos críticos son elementos impor-

Diagrama de red tantes a la hora de identificar los riesgos en el cumplimiento de las
(Network diagram)
fechas previstas para cada tarea.
Estimaciones de Los requisitos de tiempo y costes de alto nivel ayudan a identificar

tiempo y coste riesgos en ambas materias. Son una entrada para la gestión de los ries-
(Time and cost esti- gos del proyecto cuando éstos están definidos inicialmente y un resul-
mates) tado cuando éstos están definidos con más detalle.
Plan de Gestión de Ayuda a identificar qué recursos están disponibles y los riesgos deri-
Personal vados de no disponer de los recursos necesarios en el momento que
(Staff management
plan) el project manager los demande.
Hay un nexo muy fuerte entre contratos y riesgos. Por una parte un
contrato puede ser el resultado de una estrategia de transferir un riesgo
Plan de Adquisicio- pero, por otra, al no ser realizado el trabajo por personal propio, sur-
nes (Procurement gen otros riesgos que habrá que evaluar. En cualquier caso, los tér-
plan) minos y condiciones del contrato deben especificar muy bien las res-
ponsabilidades de cada parte en lo que concierne a eventos del con-
trato.
Registro de partes interesadas (Stakeholder Register)

Dentro de los documentos del proyecto, el registro de partes interesadas recoge las
necesidades y expectativas así como el interés e impacto de las diferentes partes intere-
sadas del proyecto. El registro puede utilizarse para identificar riesgos asociados a partes
interesadas o para mejor implicarles en el proceso de identificación, evaluación y defi-
nición de planes de respuesta a los riesgos.

Aspectos importantes a tener en cuenta serán la actitud y tolerancia ante el riesgo
de la compañía que indicará el riesgo que está dispuesta a asumir para lograr unos obje-
tivos más o menos ambiciosos.
Dependiendo de la compañía, la respuesta a preguntas como: ¿hay en la compañía
personas que toman excesivos riesgos?, ¿cuál es el grado de tolerancia de la compañía al
riesgo?, puede ser muy diferente. El project manager debe tener clara la posición de su
compañía en estos aspectos.

El project manager debe ser consciente de si en la compañía hay ya plantillas defi-
nidas, definiciones comunes de términos y conceptos, funciones y responsabilidades (y
niveles de autoridad) para la toma de decisiones sobre riesgos, formatos de declaración
de riesgos, categorías de riesgos que la compañía utilice para clasificar y apoyarse en la
identificación de los riesgos. Asimismo, puede tener registros de riesgos de otros pro-
yectos similares que pueden servir de base para su propio registro.
El project manager utilizará técnicas analíticas y reuniones en las que recoger el

juicio de expertos en diferentes áreas tanto técnicas como de gestión, tanto expertos en
procesos de producto, de proyecto y de apoyo.

El project manager hará bien en apoyarse en la dirección, partes interesadas del
proyecto, project managers con experiencia en proyectos similares o expertos en aspec-
tos concretos del proyecto para establecer cómo se van a gestionar las reservas de con-
tingencia, para asignar las responsabilidades en la gestión de riesgos y para adecuar –o
elaborar si no existen– los mapas y categorías de riesgos, las matrices probabilidad-
-impacto...y otros elementos al contexto específico del proyecto.

La principal técnica de análisis de datos a aplicar en este proceso será el análisis de
interesados, que permitirá determinar la tolerancia al riesgo de los interesados del pro-
yecto.
En una primera reunión de inicio, el orden del día debe incluir la revisión de lec-
ciones aprendidas de proyectos anteriores similares y la revisión de todos los documentos
del proyecto –los ya indicados como entradas y si, es necesario, los posibles contratos
existentes, las especificaciones del producto o servicio o los diagramas de disponibilidad
de recursos…– para que el equipo sea consciente de todas las fuentes de riesgos poten-
ciales.
Deberá concluir en un acuerdo sobre el proceso que se seguirá y las técnicas y
herramientas que se utilizarán en la planificación de riesgos asociados al proyecto.
Es importante reservar tiempo para planificar los riesgos del proyecto. Esto se puede
conseguir convocando reuniones periódicas o específicas para analizar temas relativos a
riesgos. A ellas asistirán el Director del Proyecto, el Equipo de proyecto, los interesados
relevantes y cualquier persona de la organización con responsabilidades sobre la plani-
ficación y ejecución de actividades relacionadas con riesgos y el personal externo que,
en cada momento, se considere conveniente.
En estas reuniones:
• Se definen los planes generales de gestión de los riesgos del proyecto.
• Se elaboran los elementos de costes de riesgos y sus actividades para incluirlos
en el presupuesto y el cronograma.
• Se revisan las metodologías para la aplicación de las reservas de contingencias.
• Se asignan los responsables de la gestión de los riesgos del proyecto.
• Se revisan y actualizan las plantillas para las categorías de riesgos ya existentes.
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtendrá el Plan de Gestión de Riesgos que

incluirá, entre otros, los siguientes elementos:
• La metodología –método, herramientas y fuentes de datos para realizar la gestión

de riesgos–.
• Los roles y responsabilidades –definiendo el equipo que gestiona, apoya y lidera
la gestión de cada actividad de gestión de riesgos–.
• El presupuesto –tanto el reservado para la gestión de riesgos como los criterios
para definir y disponer de las reservas de contingencia y gestión del proyecto–.
• El cronograma –tanto de actividades de gestión de proyectos como los criterios
para definir y disponer de las reservas de contingencia del cronograma–.
• Las categorías de riesgos –estructura en la que se clasifican los diferentes riesgos
identificados por la organización y que ayudará a la identificación de nuevos–.
• Las definiciones y niveles de impacto y probabilidad de riesgo –adaptando las
de la organización al contexto del proyecto–.
• Las matrices de probabilidad impacto –para clasificar los riesgos en función de
la probabilidad de ocurrencia e impacto en los objetivos del proyecto–.
• Y otros aspectos como las tolerancias al riesgo de las partes interesadas, formatos
de reporte y seguimiento.
El Plan de Gestión de los Riesgos del proyecto (Risk management plan)

El Plan de Gestión de Riesgos debe estar adaptado al tamaño y complejidad del
proyecto y tener en cuenta la experiencia en proyectos similares. Define cómo se va a
estructurar y llevar a cabo el proceso de gestión de los riesgos del proyecto y será una
entrada –en una primera iteración– para el desarrollo del alcance, cronograma, presu-
puesto y Plan de Calidad ya elaborados. Contará con los siguientes apartados:
En la que se incluyen los métodos y procedimientos, herramientas y

Metodología fuentes y flujos de información a utilizar durante la gestión de los riesgos
(Methodology)
del proyecto.
Que permitan que cada cual sepa lo que tiene que hacer en cada
momento y a quién informar. Será clave dejar bien claras y definidas las
Roles y responsabi- funciones y responsabilidades así como las transiciones entre unas y otras.
lidades (Roles and Para ello se define al líder, los apoyos y los miembros del equipo de
responsabilities) gestión de los riesgos del proyecto. Suele generarse una matriz de asig-
nación de responsabilidades (risk responsibility assigment matrix, RAM)
específica para la gestión de riesgos en proyectos complejos.
El Plan de Gestión debe tener un presupuesto asignado, como lo puedan

tener otros documentos como los planes de seguridad. Llevará implícita
Presupuesto una asignación de recursos y una estimación de los costes necesarios para
(Budget): la gestión de los riesgos que se incluirá en la línea base del desempeño
de costes. Asimismo establecerá los protocolos para el uso de las reservas
de contingencia.
Define cuándo y con qué frecuencia se realizará el proceso de revisión
y actualización de los riesgos del proyecto y su gestión durante el ciclo
Calendario de vida del proyecto.

(Calendar) Al establecerse los protocolos para la utilización de las reservas del cro-
nograma se definirán las actividades relacionadas con la gestión de riesgos
que deberán incorporarse al calendario y cronograma del proyecto.
Cada empresa puede utilizar una metodología para categorizar los riesgos
que permita una identificación sistemática de los mismos con un nivel
de detalle coherente para identificar los riesgos de forma adecuada y
eficiente.
Los categorías pueden basarse en el origen:
Categorías de • Procedentes de las partes interesadas y en este caso en función:
riesgo – del origen (el cliente, una inadecuada gestión del proyecto, el pro-
(Risk categories) veedor, la cultura de empresa, el sistema de comunicaciones, la existencia
de un equipo virtual…), o
– sobre qué objetivo impactan (coste, tiempo, calidad, satisfacción del
cliente, reputación de la empresa…).
• Externas o técnicas
Las tres formas más comunes de generar las categorías son las basadas en:
Estructura de desglose de riesgos (risk breakdown structure,

RBS)
Como ocurría con la estructura de desglose de tareas, va identificando
áreas de riesgo –técnicas, financieras, legales, de venta…– y en cada una
de ellas identifica nuevos riesgos que, a su vez, pueden incluir nuevos
riesgos.
La siguiente figura nos da una idea simplificada de lo que puede ser una
RBS. El objetivo de este método es que permita asignar cada riesgo a
una de las categorías definidas (y, si puede ser, buscar soluciones únicas
que resuelvan varios riesgos, ganando en eficiencia).
Categorías de
riesgo
(Risk categories)
Una RBS es de gran ayuda para recordar áreas y riesgos concretos.

Cuanto más detallada sea, más útil será. Estas categorías pueden estar
establecidas por la empresa, que el equipo de proyecto las cree o que
adapte las generales al caso concreto.
Además será muy útil para en fases posteriores definir soluciones con-
juntas para riesgos englobados dentro de una misma categoría.
•El flujo de trabajo
Categorías de Es el flujo de trabajo necesario para realizar el proceso completo y cada
riesgo uno de sus subprocesos donde para cada actividad y cada interfase entre
(Risk categories) tareas se identifica riesgos en las tareas, en las transferencias de informa-
ción, en los puntos de decisión… Se analizan los procesos, las interfaces,
los flujos de información y entrega y en ese análisis se detectan posibles

orígenes de riesgos.
• La estructura de desglose de tareas
La identificación de riesgos se puede realizar una vez se haya elaborado
la estructura de desglose de tareas identificando los riesgos para cada
actividad.
El análisis cualitativo de riesgos tiene por objetivo definir diferentes
niveles de probabilidad e impacto para cada riesgo que permita generar
una lista priorizada de los mismos.
Es importante que estos niveles estén definidos por la propia empresa
para evitar evaluaciones subjetivas y poder hacer análisis comparativos
entre diferentes proyectos de, por ejemplo, una misma cartera o pro-
grama de proyectos.
Las escalas podrán ser cualitativas (muy alto, alto…) o numéricas (pro-
babilidad del 0,2, 0,4…). Estas clasificaciones valen para ambos paráme-
tros. Sin embargo, en ocasiones las compañías, a la hora de clasificar los
impactos utilizan escalas no lineales para evitar las amenazas de alto
impacto o aprovechar las oportunidades de alto impacto –las escalas no
lineales permiten asignar un nivel o valoración muy superior conforme
aumenta la probabilidad o el impacto–.
Esta tabla que se presenta como ejemplo de lo tratado, cambiará de una
empresa a otra dependiendo de su estrategia (agresiva, conservadora…),
del sector en el que se mueva (dinámico y muy competitivo o consoli-
Definiciones de dado y más estable), o del proyecto (existe experiencia o es una nueva
probabilidad e tecnología no desarrollada con anterioridad).
impacto
Definiciones de Esta tabla ayudará a que el project manager comprenda los niveles de
probabilidad e riesgo (combinación de la probabilidad e impacto) que la compañía
impacto considera aceptables o inaceptables.
Para priorizar los riesgos de acuerdo a su probabilidad e impacto en el

Matriz de
probabilidad e proyecto se crean matrices o gráficas que sitúe cada riesgo según estos
impacto dos parámetros –y de acuerdo a los niveles establecidos por la compañía–.
(Probability and De esta manera el project manager puede identificar aquellos más rele-
impact matrix) vantes y priorizarlos:
Hay que recordar que puesto que los límites de los niveles que definen
estas matrices tienen una parte importante de subjetividad, conviene
utilizar niveles de probabilidad e impacto estándar de la compañía para
que las interpretaciones sean más sencillas y coherentes entre proyectos.
Dependiendo del sector, tipo de empresa y entorno económico las tole-

Tolerancias rancias al riesgo variarán sustancialmente. Este será un elemento que el
revisadas de los
interesados project manager deberá consensuar con el patrocinador (sponsor) y la
alta dirección en el marco del proceso planificar la gestión de riesgos.
Definen cómo se documentarán, analizarán y comunicarán los resultados

Formatos de de los procesos de gestión de los riesgos del proyecto y los contenidos y
informe
formatos a utilizar.
Da criterios para documentar todas las incidencias que ocurran en la
ejecución del proyecto para mejorar el proyecto actual y los futuros
proyectos que podrán tener un listado más completo de experiencias y
Seguimiento
evitar, al menos, los errores ya cometidos.

Asimismo documenta si los procesos de gestión de los riesgos del pro-
yecto se someterán a auditoría y con qué protocolo.
Este plan será entrada para los siguientes cuatro procesos del grupo de procesos de
planificación relativos a riesgos.
3.10.2. Identificar los riesgos

Este proceso tiene por objetivo determinar qué riesgos pueden afectar al proyecto
y documentar sus características. Entre las personas y entidades que pueden participar
en esta identificación de riesgos están el project manager y el equipo de proyecto, los
clientes, expertos en partes del proyecto, usuarios finales, otros project managers, partes
interesadas y expertos en gestión de riesgos.
Es un proceso vivo e iterativo que se actualizará conforme avance el proyecto a lo

largo de su ciclo de vida ya que es posible identificar riesgos en todas las fases del pro-
yecto:
• Inicio, donde se identifican riesgos globales, de alto nivel.
• Planificación, donde se identifican la mayor parte de los riesgos, que no se puede
dar por cerrada hasta completar la EDT que, a su vez, no se podrá cerrar hasta
que se haya definido el Plan de Respuestas a los Riesgos.
• Fase de ejecución y supervisión y control, donde pueden aparecer riesgos no
previstos o desaparecer riesgos contemplados.
Por todo ello y por su criticidad, el project manager debe estar atento a los riesgos
del proyecto desde que se discute el proyecto por primera vez –si ya ha sido designado
como project manager, como es recomendable–, durante la planificación y también
durante la fase de ejecución, seguimiento y control.
Antes de iniciar el proceso por el cual logremos identificar todos los riesgos que
pueden afectar positiva o negativamente al proyecto, conviene valorar el alcance y la
situación actual del proyecto para, en primer lugar, decidir:
• Qué parte del proyecto será tratada en el proceso de identificación de riesgos:
todo el proyecto, una de sus fases, las actividades de mayor valor añadido, las
tareas críticas…
• De qué información se dispone y qué información se distribuirá a cada parte
interesada. Parece lógico que algunos riesgos no se comuniquen inmediata-
mente al cliente. También habrá información confidencial que el equipo de
proyecto no necesitará conocer antes del inicio del proyecto.
• Qué expertos en el tema deben integrarse en el proceso y qué técnicas de iden-
tificación se utilizarán.
Este esquema ubica el proceso de identificación de riesgos dentro de su área de
conocimiento y su grupo de procesos dentro de las fases del proyecto:
En el esquema siguiente se sintetiza el proceso de identificación los riesgos (identify

risks) que se desarrolla a continuación:
En ISO21500 existe un proceso de objetivos y contenido similar «Identificar riesgos» que

pretende identificar eventos de riesgo potenciales y sus características que, en caso de que se
materialicen, puedan tener un impacto positivo o negativo en los objetivos del proyecto.
Remarca que es un proceso repetitivo puesto que pueden aparecer nuevos riesgos a lo largo
de toda la vida del proyecto. Este proceso, para ser completo, debe involucrar a múltiples par-
ticipantes, entre ellos los clientes, patrocinador, project manager, equipo de dirección de proyecto,
alta dirección, usuarios, expertos...
Entradas Salidas
Planes de proyecto Registro de riesgos
IDENTIFICAR LOS RIESGOS (IDENTIFY RISKS)

La identificación de riesgos es un método estructurado y consistente para la iden-
tificación de eventos potenciales de riesgo y documentar sus características. Debe
producir en una lista de eventos de riesgo, positivos (oportunidades) o negativos
(riesgos o amenazas) con una descripción clara y específica de cada evento de riesgo.
ENTRADAS (INPUTS):
Entre la información necesaria para identificar los riesgos están el Plan de Gestión
de Riesgos –que asigna roles y responsabilidades en la identificación de riesgos o recoge
las categorías de riesgo a utilizar en este proceso–, los planes de gestión de costes, plazos,
calidad y recursos –que recogen los procesos para definir y mantener el presupuesto, el
alcance, el cronograma, el equipo... que pueden verse afectados como resultado de
identificar riesgos–, la línea de base del alcance –donde se encuentran las hipótesis de
proyecto y la EDT elemento crítico para identificar riesgos asociados a los paquetes de
trabajo y entregables que hay que ejecutar–, las estimaciones de duración y costes de
cada actividad –que, dependiendo de la información disponible, llevarán asociados ries-
gos de que no se cumplan–, el registro de partes interesadas –cuyas necesidades o expec-
tativas puede llevar asociado algún riesgo al proyecto–, acuerdos –donde pueden encon-
trarse riesgos relacionados con los términos y condiciones del contrato–, documentos
de contratación (adquisiciones) –donde pueden encontrarse riesgos asociados a las com-
pras o adquisiciones–, los factores ambientales de la empresa y los activos de los procesos
de la organización –archivos de proyecto, lecciones aprendidas...–.
Plan de Gestión del Proyecto (Project management plan)

Los principales componentes del plan de gestión del proyecto que serán utilizados
como entrada de este proceso son:
• Plan de gestión de requisitos. Puede marcar los objetivos del proyecto que están
especialmente en riesgo.
• Plan de gestión del cronograma. Describe los procesos y herramientas para
identificar actividades, secuenciarlas, estimar los recursos necesarios y duraciones
de cada actividad y elaborar el cronograma. En estos procesos se pueden iden-
tificar riesgos asociados a los datos de partida para la estimación, asociados al
diagrama de red –cuando, por ejemplo, una tarea crítica depende de varias pre-
cedentes–, asociados a los recursos necesarios o asociados a la existencia de más
de un camino crítico o cuasi-crítico. También definirá entre otras cosas cómo
se incorporan las reservas de contingencia a la línea base del cronograma.
• Plan de gestión del coste. Este plan definirá entre otras cosas cómo se incorporan
las reservas de contingencia –a la línea base del presupuesto– y las de gestión –
al presupuesto–. Asimismo indica cómo realizar las estimaciones y cómo ela-
borar el presupuesto, aspectos que pueden ayudar a identificar riesgos asociados.
• Plan de gestión de la calidad. El Plan de Gestión de la Calidad que define métri-
cas, responsables y actividades de aseguramiento y control de calidad, ayudará
durante su elaboración a identificar riesgos asociados al cumplimiento de los
requerimientos del producto o proyecto.
• Plan de gestión de recursos. Al definir roles y responsabilidades y definir las
necesidades de personal, permitirá identificar riesgos asociados a la disponibili-
dad de los recursos humanos necesarios para completar los paquetes de trabajo
asignados.
• Plan de gestión de riesgos. Es precisamente el documento que define cómo se
va a realizar el proceso de identificación de riesgos –utilizando qué información,
implicando a qué partes interesadas...–.
• Línea base de alcance. Por una parte, en el Enunciado del alcance del proyecto
se recogen las hipótesis de partida que pueden ser origen de riesgos al no cum-
plirse, por otra parte la EDT, que recoge todo el trabajo que es necesario hacer
para completar el proyecto y cumplir con sus objetivos, será una fuente impor-
tante para recoger riesgos asociados a cada componente de la EDT.
• Línea base de cronograma. Deberá revisarse para identificar aquellos hitos y
fechas de entrega intermedias que sean susceptibles de cierta incertidumbre o
ambigüedad. También aquellas asunciones de conograma que puedan esconder
riesgos.
• Línea base de coste. Del mismo modo deberán revisarse las estimaciones de coste
realizadas bajo cierta ambigüedad o incertidumbre, pues estas estimaciones
seguramente esconderán riesgos.

Entre los documentos de proyecto que conviene analizar están:
• Registro de asunciones. Las asunciones y restricciones ocultan riesgos que deben
ser identificados tras analizarlas.
• Estimaciones de coste. Las hipótesis de partida para la estimación de costes así
como, en caso de que se utilicen, la expresión del coste como probabilidad de
que una actividad tenga un coste mayor de una cantidad determinada, serán
elementos a tener en cuenta a la hora de identificar riesgos asociados con el
cumplimiento de los objetivos de coste.
• Estimaciones de duración. Como en el caso anterior, las hipótesis de partida
para la estimación de duraciones –sobre todo cuando se exprese como una fun-
ción de probabilidad– serán elementos a tener en cuenta a la hora de identificar
riesgos asociados con el cumplimiento de los objetivos de plazo.
• Registro de incidencias. El registro de incidencias podría elevar el nivel de riesgo

del proyecto, si por ejemplo se identifica que el número de incidencias es con-
siderablemente más alto de lo previsto.
• Registro de lecciones aprendidas. Se revisará para determinar si es posible que
riesgos identificados en un momento temprano del proyecto pudieran volver a
producirse.
• Documentación de requisitos. Se revisarán los requisitos tratando de identificar
aquellos que puedan estar en riesgo.
• Requerimientos de recursos. Deberá analizarse el grado en el que el número de
recursos requeridos es cubierto por los recursos disponibles para el proyecto.
• Registro de interesados. Se podrá utilizar tanto para saber a quién solicitar inputs
para el registro de riesgos como para identificar riesgos asociados al cumpli-
miento de las necesidades y expectativas de las diferentes partes interesadas, muy
especialmente aquellas con alto interés e impacto en el proyecto.
Documentos de adquisiciones (Procurement documents)

En caso de que parte del trabajo del proyecto vaya a subcontratarse, los documentos
de compras elaborados serán entradas clave para identificar riesgos.
Factores ambientales de la empresa (Enterprise Environmental factors)

Entre los factores que pueden influir se encuentran la información publicada en
bases de datos comerciales, las investigaciones académicas en el ámbito tecnológico del
proyecto, las listas de control, estudios comparativos y estudios industriales publicados
en relación a los riesgos que tienen los proyectos similares al que se va a desarrollar.
El project manager se deberá documentar también sobre cuál será la actitud de la
compañía ante el riesgo, sus áreas de riesgo y los umbrales de riesgo no aceptables. En
este sentido el patrocinador será el interlocutor.

Se tendrá en cuenta:
• La información detallada del proyecto, lo que hacen otras compañías, artículos
y toda clase de documentación que ayude a identificar más riesgos.
• Información histórica de proyectos similares que alertará sobre riesgos de ante-
riores proyectos.
• Lecciones aprendidas de proyectos anteriores que ayudarán a identificar, mitigar
y gestionar riesgos del proyecto que pudieron surgir en aquellos.
• Procedimientos, políticas y formatos de la organización que estandarizan la
forma de desarrollar las actividades de gestión de los riesgos del proyecto en la
organización.
• Las estimaciones de los costes de las actividades que ayuden a evaluar cuantita-
tivamente el coste probable del proyecto. Idealmente deberán estar expresadas
por un intervalo de confianza de una determinada probabilidad. Cuanto más

amplio sea el intervalo, mayor será la incertidumbre y mayor el riesgo.
• Las estimaciones de duración de cada actividad que ayudarán a estimar los tiem-
pos del proyecto muy especialmente si se conoce la media y su desviación para,
como en el caso anterior, poder definir intérvalos de confianza y conocer grados
de incertidumbre.
Para identificar los riesgos del proyecto, se debe realizar una revisión estructurada
de la documentación del proyecto, incluyendo los planes, hipótesis, archivos de pro-
yectos anteriores, contratos y otra información relacionada con el proyecto.
Además se pueden utilizar técnicas de generación de ideas –como las tormentas de
ideas o el método delphi–, realizar entrevistas a personas y entidades relevantes dentro
del proyecto y la organización, y realizar análisis de la causa raíz que permitan una
definición del riesgo que facilite la posterior definición de la acción de mitigación o
respuesta.
Es especialmente útil, al identificar los riesgos, generar listas de chequeo y mapas de
categorías de riesgos actualizados y depurados al final de cada proyecto o analizar los
registros de suposiciones, asunciones y escenarios del proyecto, explorando su validez,
consistencia, estabilidad, exactitud...
De igual manera se pueden utilizar diagramas causa-efecto, diagramas de flujo del
proceso, análisis DAFO u el juicio de expertos con experiencia relevante en proyectos
o áreas de negocio similares.
Consultas a expertos (Expert judgment)

Con la información existente se solicita a expertos opinión e información general,
documentando la entrevista para incorporar a la lista de riesgos aquellos que hayan salido
a la luz. Como ejemplo, el equipo de proyecto necesita buscar un lugar adecuado para
comenzar los trabajos de obra civil y el project manager llama a un geólogo, un meteo-
rólogo… y les solicita una valoración de los riesgos geotécnicos de la ubicación.

Tormentas de ideas (Brainstorming):

Se suele realizar con un grupo multidisciplinar de expertos que no pertenecen al
equipo. Pueden utilizarse o no categorías de riesgo. La clave es que las ideas no se
juzguen, discutan ni comenten sino que, conforme cada experto va identificando ries-
gos, el resto pueda ir descubriendo otros nuevos.
Se puede realizar mediante una sesión tradicional abierta o en una sesión estructurada
donde se utilicen técnicas de entrevista en grupo como, por ejemplo, las técnicas de
grupo nominal.
Las técnicas de grupo nominal tienen cuatro fases:
– Generación en silencio de ideas que se ponen por escrito.
– Retroalimentación por turnos de los miembros del grupo con el fin de registrar
en la pizarra cada idea en una frase concisa.
– Discusión de cada una de las ideas registradas, con fines de aclaración y depu-
ración.
– Votación individual sobre la prioridad de las ideas.
– La decisión del grupo se obtiene matemáticamente mediante la ordenación por
categorías o puntuación.
Luego los riesgos son identificados y categorizados según su tipo y se ajustan las
definiciones para que sean realmente informativas del evento de riesgo.
Listas de control (checklists)

Se pueden utilizar cuestionarios, listas de control..., que se elaborarán basándose en
la información histórica y el conocimiento acumulado de otros proyectos. En ocasiones
se utiliza el nivel inferior de la estructura de desglose de tareas, EDT.
Con la información existente se solicita a expertos opinión e información general,
documentando la entrevista para incorporar a la lista de riesgos aquellos que hayan salido
a la luz. Como ejemplo, el equipo de proyecto necesita buscar un lugar adecuado para
comenzar los trabajos de obra civil y el project manager llama a un geólogo, un meteo-
rólogo… y les solicita una valoración de los riesgos geotécnicos de la ubicación.
Técnica Delphi (Delphi technique)

Un grupo de expertos en proyectos participan de forma anónima. Para ello,
a) el project manager les facilita un cuestionario para identificar riesgos del pro-
yecto,
b) la síntesis de las respuestas es reenviada a todos los expertos,
c) ellos, tras su revisión, proceden a elaborar una nueva lista de riesgos,
d) se repite el proceso desde b) hasta lograr una lista de riesgos consensuada.
Su gran ventaja es el anonimato en el que se trabaja ya que:
– permite una mayor libertad para escribir y para cambiar de opinión,
– evita la distorsión de datos, y
– evita que cualquier persona ejerza influencias desproporcionadas sobre el grupo.
Un ejemplo sería si el project manager, ante un problema técnico grave en las juntas
de dilatación de un puente atirantado, consulta con cuatro expertos en la materia;
cuando recibe sus informes, los revisa, elimina el nombre del autor y reenvía a cada
experto los informes de los otros tres; en ese momento, cada experto valora si reconsidera
su opinión a la luz de las conclusiones del resto.

Las principales técnicas de análisis de datos que se utilizan en este proceso son:
Análisis de causa raíz (Root cause analysis)

Una de las maneras más útiles de llegar a esa causa es utilizar el método de los «5
porqués» desarrollado por Toyoda en los años 50.
Análisis de asunciones y restricciones (Assumption and constraint analysis)

Detrás de cada hipótesis, asunción, condición de partida está el riesgo de que no se
cumpla. Por lo tanto, un listado de éstas será una buena fuente de identificación de
riesgos.
Para ello se debe explorar la validez cada una de ellas e identificar los riesgos debidos
a la inexactitud, inestabilidad, incoherencia o falta de información.
Si el cronograma de ejecución de una obra de urbanización supuso que los días de
lluvia medios al año en la zona eran 60 y, a mitad de obra ya se llevan 60 y pueden llegar
a 120, la obra se retrasará. La hipótesis de partida, recogida probablemente de datos
estadísticos oficiales, conllevaba el riesgo de no cumplirse. Por lo tanto, al inicio del
proyecto, se debería contemplar el evento riesgo de que sea una temporada más lluviosa
de lo habitual.
Análisis DAFO (SWOT analysis)

Es una herramienta clásica de los análisis estratégicos de las empresas que puede
utilizarse con éxito en el análisis de riesgos en proyectos. Sin ser objeto de este docu-
mento una descripción de la metodología completa, baste con indicar que trata de
identificar:
– Fortalezas (Strenghts) y debilidades (Weaknesses) internas de la empresa relativas
al proyecto.
– Oportunidades (Opportunities) o amenazas (Threats) externas a la empresa y al
proyecto.
Análisis de documentos (Document analysis)

Se refiere a la documentación de proyecto ya elaborada hasta el momento: las hipó-
tesis de partida, la documentación de proyectos anteriores como los riesgos que se
detectaron o que aparecieron sin haber sido identificados. Por ejemplo, antes de comen-
zar la identificación de riesgos el project manager consulta los documentos fin de obra
de proyectos anteriores y toma nota de los problemas que surgieron durante la obra.
Habilidades interpersonales y de equipo (Interprersonal anda Team Skills)

Como habilidad que permite guiar al grupo hacia decisiones satisfactorias. El faci-
litador realiza una labor de liderazgo, asegurando la participación y el correcto enten-
dimiento por parte de los participantes en una reunión. Además, deberá asegurar el
acuerdo de todas las partes en las conclusiones obtenidas.
Lista de avisos (Prompt lists)

Se trata de una lista predeterminada de categorías de riesgos que puede ser utilizada
de cara a la identificación de riesgos, puesto que guiará al equipo en la generación de
ideas para identificar riesgos.
Existen marcos estratégicos que sirven como herramientas para facilitar la identifi-
cación de riesgos, como por ejemplo PESTLE (político, económico, social, tecnológico,
jurídico, medioambiental), TECOP (técnico, medioambiental, comercial, operacional,
potttieal) o VUCA (volatilidad, Incertidumbre, complejidad, ambigüedad).
La mayor parte de las reuniones orientadas a la identificación de riesgos se combinan
con técnicas como tormentas de ideas.
El Project manager deberá utilizar sus habilidades como facilitador para llevar por
buen rumbo las reuniones de identificación de riesgos, teniendo además muy en cuenta
quienes deben asistir a las mismas. A este respecto, son habituales en este tipo de reunio-
nes el patrocinador, expertos en la materia del proyecto, proveedores y representantes
del cliente.
SALIDAS (OUTPUTS):
Como salidas de este proceso está el registro de riesgos, documento en el que se

recogen los riesgos identificados y definidos con esquema del tipo «si el Evento ocurre,
puede causar un Impacto en el proyecto» o «Si se produce Causa, entonces el Evento
puede ocurrir, provocando el Efecto en el proyecto» que identifican y separan la causa
del evento y de su impacto.
Registro de riesgos (Risk registers)

El resultado es una ficha con la estructura y contenido de la tabla siguiente. En
procesos sucesivos se irá completando con los resultados del análisis cualitativo, análisis
cuantitativo, acciones de respuesta..., que se vayan obteniendo como resultados.
Se describen los riesgos identificados, sus causas y las hipótesis de

Lista de riesgos identifi- partida del proyecto. Se deben describir de tal manera que se
cados entienda qué implican. Hay que evitar descripciones de riesgos
(Risk register) ambiguos o mal definidos.
Si definimos el riesgo como «Que el manual de formación no esté

preparado tendremos un problema», dará poca información. Si se
describe como «Si el Manual de Formación no está desarrollado y
revisado para la segunda semana de marzo, puede producir un
retraso de más de tres semanas en la entrega final del curso y más de
4 semanas en la instalación del software». De esta manera indicamos
el evento de riesgo, su impacto y la solución (cumplir esa fecha). Y
el riesgo está claro.
A Guide to the Project Management Body of Knowledge
(PMBOK®Guide)–Sixth Edition, Project Management Institute, Inc.,
2017, propone dos fórmulas para su enunciado:
• Un evento X puede ocurrir, causando un impacto Y determi-
nado.
• Si se produce una causa X, un evento Y puede ocurrir, pro-
vocando un efecto Z.
Al identificar el riesgo se pueden ir avanzando posibles respuestas
Lista de posibles res- que se recogen en este apartado. Estas respuestas u otras más ajus-
puestas tadas y perfectamente definidas al tener más información del pro-
(List of potential solu-
tions) yecto, se incorporarán a este apartado en el proceso de elaboración
del Plan de Respuestas a los Riesgos.
Además de la lista de riesgos identificados, se elabora una lista de

Causas de los riesgos causas o condiciones que pueden dar lugar a uno o varios riesgos
(Risk root causes) identificados. Éstas se registran y utilizan para apoyar la identifica-
ción futura de riesgos de éste u otros proyectos futuros.
Tras este proceso de identificación de riesgos pueden identificarse
Categorías de los riesgos nuevas categorías. Con estas nuevas categorías se actualizará la
actualizadas estructura de desglose de riesgos.
(Updated risks catego- En sentido contrario, al elaborar las categorías de riesgos, se puede
ries) descubrir un nuevo riesgo que se deberá incluir en la estructura de
desgloses de riesgos y en el registro de riesgos.
Son indicadores, señales o síntomas de que un evento de riesgo va
a ocurrir. Si bien no se incluyen en el registro de riesgos es impor-
Indicadores de riesgo tante definirlos y controlar su evolución para poder actuar cuanto
(Risk parameters)
antes, preparando y poniendo en marcha el Plan de Respuesta para
minimizar su impacto.
Informe de riesgos (Risk report)

Además del registro de riesgos, se creará un informe de riesgos, con información
sobre la situación de los riesgos. Este documento está basado en la información contenida
en el registro de riesgos y será desarrollado progresivamente, recogiendo la salida de cada
proceso de gestión de riesgos y reflejando la situación respecto a los riesgos a lo largo
de la vida del proyecto.
En el proceso de identificación de riesgos, el registro de riesgos contendrá al menos:
• Fuentes de los riesgos, indicando cuales son los factores más importantes de
exposición al riesgo en el proyecto
• Resumen de los riesgos identificados para el proyecto indicando por ejemplo el

número de amenazas y oportunidades identificadas, la distribución de los riesgos
por categorías de primer nivel, etc.
Actualizaciones a los documentos del proyecto (Project documents upda-
tes)
Fruto de este proceso pueden verse afectados los siguientes documentos del pro-
yecto:
• Registro de asunciones
• Registro de incidencias
• Registro de lecciones aprendidas
3.10.3. Realizar el análisis cualitativo de riesgos

No todos los riesgos son iguales. Algunos tendrán una gran probabilidad de ocurrir
y otros no. Algunos podrían arruinar nuestro proyecto y otros no le afectarán signifi-
cativamente. Para diferenciar este tipo de riesgos, se realiza el análisis cualitativo de
riesgos.
Este proceso tiene por objetivo priorizar los riesgos para un análisis posterior eva-
luando y combinando su probabilidad de ocurrencia con su impacto en el proyecto.
Ayuda a la organización a reducir el nivel de incertidumbre y centrarse en los riesgos
de más alta prioridad.
Este proceso evalúa la prioridad de los riesgos identificados utilizando su probabi-
lidad relativa de ocurrencia y el correspondiente impacto en los objetivos de proyecto
si el evento se materializa. Asimismo se consideran otros aspectos como el tiempo dis-
ponible para actuar y la tolerancia al riesgo de la organización en relación a las restric-
ciones del proyecto (alcance, tiempo, coste, calidad...).
Para hacer una evaluación efectiva es, por tanto, necesario identificar y gestionar
explícitamente las actitudes al riesgo de las partes interesadas más relevantes. Como estas
actitudes puede introducir sesgos entre unos proyectos y otros y entre unas partes
interesadas y otras dentro del mismo proyecto, el establecimiento de niveles de proba-
bilidad e impacto por parte de la organización puede reducir este sesgo.
Este proceso es una forma rápida y efectiva de establecer prioridades para el Plan de
Respuestas a los Riesgos y, si fuera necesario, establece las bases para el análisis cuanti-
tativo.
Como en el proceso anterior, este proceso debe abordarse durante la ejecución del
proyecto conforme vayan identificándose nuevos riesgos o cambien su importancia
otros.
Este proceso busca, por tanto, determinar en una escala subjetiva y cualitativa –bajo,
medio, alto, por ejemplo– la importancia de cada riesgo y, de esta manera, priorizarlos.
Para ello, se valora la probabilidad de que ocurran y su impacto en los objetivos del
proyecto. Así el project manager y su equipo pueden concentrarse en analizar con más
detalle los riesgos más importantes, no olvidando otros factores como el plazo de res-
puesta y la tolerancia al riesgo de la compañía en relación al cumplimiento de plazos,

presupuestos, calidades…
El resultado se presentará en una matriz probabilidad-impacto que, para evitar que
diferentes personas apliquen diferentes niveles de impacto, debe definirla la propia
compañía con unos criterios establecidos y aplicables a todos los proyectos. De esta
manera cuando se hable de impacto alto o de probabilidad media, tanto el project
manager como la compañía sabrán de qué están hablando y, además, podrán comparar
los riesgos de diferentes proyectos entre sí.
Este proceso se reiniciará durante la fase de ejecución del proyecto si hay variaciones
y, durante los procesos de monitorización y control de riesgos, aparecen nuevos riesgos
o alguno deja de serlo o cambia su probabilidad o impacto.
Dependiendo de los resultados de este análisis, el tipo de riesgos, la complejidad del
proyecto o lo establecido en el Plan de Dirección de Proyectos, el project manager
pasará a realizar el análisis cuantitativo de riesgos o directamente elaborará el Plan de
Respuesta.
Este esquema ubica el proceso de análisis cualitativo de riesgos dentro de su área de
conocimiento y las fases del proyecto:
En definitiva los objetivos de este proceso son:

• Graduar la probabilidad e impacto de los riesgos identificados.
• Determinar los eventos de riesgo que precisan una respuesta (y un análisis más
detallado, preferentemente cuantitativo).
• Documentar los riesgos no críticos o no prioritarios.
• Determinar cualitativamente la evaluación del riesgo global del proyecto.
• Decidir si se selecciona, se continúa o cierra el proyecto.
En el esquema siguiente se sintetiza el proceso de identificación de riesgos que
pasaremos a desarrollar a continuación.
En ISO21500 existe un proceso denominado «Evaluar los riesgos» que engloba los dos
procesos similares – «Realizar el análisis cualitativo de riesgos» y «Realizar el análisis cuan-
titativo de riesgos» de PMBOK–.
Tiene por objetivo medir el impacto y priorizar los riesgos lo cual puede llevar a calcular la
probabilidad de ocurrencia de cada riesgo y sus consecuencias sobre los objetivos del proyecto si
el riesgo ocurre.
También es un proceso repetitivo que debe realizarse de forma periódica durante la vida del
proyecto.
Entradas Salidas
Registro de riesgos Riesgos priorizados
Planes de proyecto
REALIZAR EL ANÁLISIS CUALITATIVO DE RIESGOS (PERFORM

QUALITATIVE RISK ANALYSIS)

Priorizar los riesgos evaluando y combinando su probabilidad de ocurrencia y su
impacto. En este proceso se determina cualitativamente la probabilidad de que ocurra
el riesgo y las consecuencias sobre los objetivos del proyecto, muy especialmente sus
restricciones: coste, plazo, calidad, alcance.
ENTRADAS (INPUTS):
Como información de partida para la evaluación cualitativa de riesgos se utilizará el

Plan de Gestión de Riesgos –que es parte del plan de dirección del proyecto y que
recoge los roles y responsabilidades en estas tareas, las definiciones de probabilidad e
impacto y las matrices probabilidad-impacto a utilizar en este proyecto...–, el registro
de riesgos –que contiene toda la información de los riesgos que se van a priorizar–, el
registro de asunciones- donde podríamos derivar la prioridad de algunos riesgos-, regis-
tro de interesados –donde identificaremos a los dueños de los riesgos-, el registro de

interesados, el registro de asunciones, los factores ambientales de la empresa –estudios
en el sector, bases de datos de riesgos de la organización o la industria– y los activos de
los procesos de la organización –por ejemplo, información y lecciones aprendidas de
proyectos anteriores–.
Plan de dirección del proyecto (Project management plan)

Plan de Gestión de Riesgos (risk management plan)
Es precisamente este documento el que recoge cómo se va a realizar la evaluación
cualitativa de los riesgos –técnicas y herramientas, roles y responsabilidades...–.
Integrado en el Plan de Dirección del Proyecto, define cómo va a organizarse y
llevarse a cabo el proceso de gestión de los riesgos del proyecto y es un dato de entrada
para el desarrollo del cronograma y el presupuesto de costes.
Este plan define a su vez roles y responsabilidades y niveles de toma de decisión en
la gestión de los riesgos del proyecto, los presupuestos, las actividades ligadas a esta
gestión, las categorías de riesgos, las matrices de probabilidad e impacto y la revisión de
la tolerancia por parte de los interesados.

Registro de asunciones (Assumption log)
Contiene las asunciones y restricciones del proyecto. El registro de asunciones es
usado para identificar, gestionar y monitorizar las principales asunciones y restricciones
que pudieran afectar al proyecto. Este registro sirve para ayudar a priorizar los riesgos
derivados de las asunciones y restricciones identificadas.
Registro de riesgos (risk register)

Contiene la información base para realizar el análisis cualitativo de los riesgos.
Registro de interesados (risk register)

Incluye información de todos los interesados en el proyecto. En este caso la infor-
mación relevante es la referida a los interesados dueños o responsables de los riesgos.

Se tendrán en cuenta los estudios de riesgos en el sector publicados o las bases de
datos de riesgos que hayan sido publicadas o puedan adquirirse.

• Información suficientemente detallada del proyecto, de lo que hacen otras com-

pañías, de artículos y toda clase de información que ayuda a identificar más
riesgos.
• Información histórica de proyectos similares sobre cómo se realizó la evaluación
cualitativa de los riesgos o lecciones aprendidas en proyectos anteriores. Esta
información ayudará a mejor evaluar cualitativamente los riesgos del proyecto.
• Procedimientos, políticas y formatos de la organización que estandarizan las
actividades para la evaluación cualitativa de los riesgos en la organización (plan-
tillas, matrices probabilidad-impacto…).
Para lograr desarrollar al equipo de proyecto el project manager debe evaluar la

calidad de los datos de riesgos y su validez para la toma de decisiones. Esto implica
examinar el grado en que se comprende el riesgo y la exactitud, calidad, fiabilidad e
integridad de los datos sobre el riesgo.
Utilizará también las categorías de riesgos definidas por la organización o, si procede,
los categorizará para el proyecto concreto, ya por fuentes –utilizando los mapas de ries-
gos por categorías–, por área del proyecto afectada –utilizando la EDT, por ejemplo–,
u otra categorización que sea útil. Esta categorización puede ayudar a identificar las áreas
del proyecto con mayor riesgo y definir acciones que aborden varios riesgos en su con-
junto.
La evaluación cualitativa de los riesgos se realizará utilizando las valoraciones del
impacto y probabilidad de cada riesgo. Para ello se debe definir el efecto potencial del
riesgo sobre los diferentes objetivos de proyecto –tiempo, coste, alcance, calidad– y se
debe definir la probabilidad de ocurrencia de ese riesgo. En ambos casos se debe docu-
mentar las suposiciones utilizadas para justificar el impacto o probabilidad del riesgo. La
probabilidad y el impacto se fijarán de acuerdo a los niveles definidos en el Plan de
Gestión de Riesgos. Los riesgos con alta puntuación se estudiarán con más detalle
mientras que los riesgos con menos puntuación pasarán a formar parte de una lista de
supervisión que deberá monitorizarse durante la ejecución del proyecto.
Una vez conocidos los niveles de probabilidad e impacto, los riesgos se pasan a una
matriz probabilidad-impacto que permitirá priorizar y agrupar los riesgos por su nivel
de relevancia. Es la organización la que debe definir qué combinaciones de probabilidad
e impacto resultarán en un riesgo de nivel bajo, medio o alto –que deberá estar definida
entre los activos de los procesos de la organización y adaptarse al contexto del proyecto–.
También se debe evaluar la urgencia del riesgo. Los riesgos requieren tiempos de
respuesta más o menos cortos. Pueden por tanto clasificarse entre urgentes y no urgentes
–siendo los primeros los que dan poco tiempo de actuación entre su aviso y su ocu-
rrencia–.

Casi en todos los casos será necesario el juicio de expertos a la hora de evaluar la
probabilidad y el impacto de un riesgo. Se podrá recoger a través de técnicas como el
método delphi, reuniones, talleres facilitadores...
Recopilación de datos (Data gathering)

Con la información existente se solicita a expertos u otros interesados opinión e
información general sobre los riesgos, sobretodo sobre los datos de probabilidad e
impacto, que son el objetivo principal de este proceso.

Evaluación de la calidad de los datos sobre riesgos (Risk data quality assesment)
Realizar un análisis de riesgos con datos no representativos no tiene ningún valor y
nos puede llevar a decisiones equivocadas. Por ello, es importante conocer las fuentes
–quién los tomó, cómo se tomaron, las hipótesis de partida…–. Si los datos no son fiables
o se tiene serias dudas de su fiabilidad, los análisis cuantitativos tendrán poco valor y será
necesario volver a tomarlos.
La evaluación de la precisión de los datos debe incluir las siguientes actividades:
- Evaluar hasta qué punto se entiende el riesgo.
- Evaluar los datos disponibles sobre el riesgo.
- Evaluar la calidad de los datos.
- Evaluar la fiabilidad e integridad de los datos.
Evaluación de la probabilidad e impacto de los riesgos (Risk impact and probability assesment)
Para el cálculo de valores de probabilidad e impacto se buscan medidas que describan
qué valor darle a un evento de riesgo. Estos valores se definen durante el proceso de
planificación de la gestión de riesgos.
En la fase de análisis cualitativo del riesgo, el project manager define y valora las
probabilidades e impactos para cada uno de los riesgos identificados durante el proceso
de Identificación de riesgos. Para ayudarse, puede consultar con expertos, partes intere-
sadas, miembros del equipo… y documentar no solamente la probabilidad e impacto
sino las hipótesis que se han tomado para dar dichos valores.
Los riesgos de baja probabilidad y bajo impacto se documentan para no perderlos
de vista y monitorizar su evolución. Se registrarán en una lista de supervisión o segui-
miento (Watchlist) y su evolución se seguirá durante la ejecución del proyecto.
En síntesis, esta técnica nos permite determinar qué riesgos requieren una acción y
una atención más activa y una respuesta más contundente.
Algunos conceptos básicos de probabilidad que conviene recordar son los siguientes:
- Probabilidad:
Es la posibilidad de que un suceso ocurra. En el caso de clásico de un dado, la
probabilidad de que salga un 5 será 1/6. El propósito del análisis de probabili-
dades es entender y cuantificar las posibilidades de ocurrencia de un evento de
riesgo.
Las fuentes de datos de la probabilidad serán las distribuciones teóricas que con-
sideremos que mejor explican el comportamiento del evento, los criterios sub-
jetivos del analista, las simulaciones tipo Monte Carlo o los datos históricos de
que se disponga.
- Reglas básicas de la probabilidad:
• Un conjunto de eventos es mutuamente excluyente si la ocurrencia de un
evento excluye la ocurrencia de cualquiera de los otros. O sale un 6 o no
sale un 6.
• Las probabilidades se expresan en decimales entre 0 (el suceso no ocurrirá)
y 1 (suceso seguro, el evento ocurrirá con toda certeza) o como porcen-
tajes.
• Regla de la multiplicación: si se quiere conocer la probabilidad de que un
evento y otro evento ocurran, se multiplican las probabilidades de cada
uno. La probabilidad de que salga un 6 (1/6) y en una segunda tirada un
5 (1/6) será de (1/6)*(1/6) = 1/36.
• Regla de la suma: si se quiere conocer la probabilidad de que un evento
u otro evento ocurran, se sumarán las probabilidades. La probabilidad de
que salga un 6 ó un 5 en la primera tirada (1/6 en ambos casos) la proba-
bilidad será (1/6) + (1/6) = 2/6.
• Regla de la suma total: la suma de las probabilidades de todos los eventos
posibles debe totalizar 1 (100%). La probabilidad de que saquemos un 6
(1/6) más la probabilidad de que no saquemos un 6 (5/6) nos dará 1.
• Regla de 1 menos: la probabilidad de que el evento A ocurra es 1 menos

la probabilidad de que el evento A no ocurra. Esto es la probabilidad de
que salga un 6 (1/6) es 1 menos la probabilidad de que no salga un 6 (5/6).
-
Impacto:
Es la evaluación de la consecuencia –negativa o positiva– sobre nuestro proyecto
al ocurrir un evento de riesgo. Esta evaluación puede ser cualitativa (bajo,
medio, alto) o numérica (de 0 a 1), aunque en este proceso, el valor numérico
debe entenderse como un valor cualitativo.
La tabla siguiente muestra un ejemplo de escala de impacto para el coste, el tiempo
y la calidad basada en una escala de tres niveles: bajo, medio y alto.
Objetivo Bajo Medio Alto
0,3 0,6 0,9
Plazo Aumento < 10% Aumento < 20% Aumento > 20%
Coste Aumento < 5% Aumento < 10% Aumento > 10%
Calidad Variaciones mínimas Variaciones significativas Variaciones inaceptables
Evaluación de otros parámetros sobre riesgos (Assessment of other risk parameters)

El equipo de proyecto puede considerar otras características sobre los riesgos adi-
cionales a los parámetros de probabilidad e impacto. Esas características pueden ser
principalmente:
• Urgencia. Es el período de tiempo que requiere la implementación de una res-
puesta a un riesgo para ser efectiva, de modo que si el período es corto, se trata
de un riesgo muy urgente. Este dato puede ayudar a la toma de decisiones res-
pecto a los planes a aplicar. Unos riesgos aparecen de manera súbita y otros se
ven venir con tiempo y antelación suficiente para tomar medidas. La detecta-
bilidad de los eventos de riesgos y el grado de urgencia en la acción de respuesta
son elementos críticos para una gestión de riesgos del proyecto exitosa. Se tienen
que definir y controlar los indicadores o alarmas (triggers), el tiempo necesario
para desarrollar y poner en marcha la respuesta adecuada (response time) y la
importancia global del riesgo cuando se vaya a ver con qué grado de rapidez se
actúa.
• Proximidad. Es el período de tiempo estimado que queda antes de que el riesgo
tenga un impacto sobre los objetivos del proyecto, de modo que un período
corto indica una alta proximidad.
• Latencia. El período de tiempo que transcurrirá desde que el riesgo ocurre hasta
que el impacto se descubra, de modo que un período corto indica baja latencia.
• Manejabilidad. Es un indicador de la facilidad con la que el dueño o responsable
del riesgo puede gestionarlo.
• Grado de control. Se refiere al grado de control que puede llegar a tener el
dueño o responsable del riesgo sobre el mismo.
• Perceptibilidad. Se refiere a la facilidad con la que puede ser identificado un
riesgo que está ocurriendo.
• Conectividad. Mide la posible relación entre un riesgo y otros riesgos relacio-
nados. Cuando un riesgo está conectado a muchos riesgos, se habla de alta
conectividad.
• Impacto estratégico. Un riesgo con impacto estratégico alto es un riesgo cuyo
impacto (positivo o negativo) afecta directamente a los objetivos estratégicos de
la organización.

Categorización de riesgos (Risk categorization)

Si tenemos los riesgos categorizados por:
• fuentes de riesgos (técnicos, financieros, legales…),
• área del proyecto afectada (actividad correspondiente de la EDT),
• sus causas raíz comunes, u
• otras como el área de conocimiento o la fase del proyecto (project phase),
entonces podremos analizar las áreas del proyecto que se encuentran más expuestas
a los riesgos y además puede permitir definir actuaciones comunes para grupos de riesgos
análogos, o con una misma causa raíz de una misma fase del proyecto.
Ejemplos típicos de categorizaciones con estos criterios serían los siguientes:
• Calidad, desempeño o • Externos: • De proveedores:

tecnología - Regulaciones - Incumplimiento de fechas de
• Gestión del proyecto - Ambientales proveedores
• Organización - Gubernamentales -Incumplimiento de estándares de
• Externos - Cambios de mercado calidad del proveedor
• Internos: • Definición del alcance o
- Tiempo requisitos del trabajo
- Costes • Recursos:
- Cambios de alcance - Recursos no apropiados que
- Inexperiencia aumentan la duración de las tareas
- Planificación pobre
- Personas
- Reclutamiento
- Materiales
- Equipos
- Tecnológicos
• Imprevisibles
Representación de datos (Data Representation)

Matriz de probabilidad e impacto (Probability and impact matrix)
Los riesgos se priorizan en función del nivel de probabilidad o impacto definidos
por la organización al inicio del proyecto y que están incluidos en los activos de los
procesos de la compañía. Habitualmente se realiza mediante una tabla de búsqueda o
una tabla de matriz-impacto que se describe a continuación.
De la matriz de probabilidad e impacto se obtendrá una visión de la importancia de
cada riesgo identificado en el proyecto. La combinación de la probabilidad y el impacto
dan como resultado una clasificación de los riesgos en altos, medios y bajos (negros,
grises y blancos en la siguiente figura).
Siguiendo con el ejemplo de la tabla anterior, supongamos que hemos identificado

un riesgo que podría tener un impacto en los costes del proyecto y que los expertos y
las estimaciones realizadas por el project manager y su equipo estiman que producirá un
aumento en el presupuesto del 7%: implicaría un impacto medio según la tabla de escalas
de impacto y le daríamos un valor de 0,6.
Además los expertos, teniendo en cuenta los datos históricos de proyectos similares,
consideran que la probabilidad de que ocurra es de un 40%, un 0,4.
Con el ejemplo anterior y a partir de una matriz impacto-probabilidad elaborada
por la empresa (tabla siguiente), analizamos nuestro riesgo que tendrá una probabilidad
de 0,4 y un valor del impacto de 0,6.
Entrando con el 0,6 en las columnas y con el 0,4 en las filas, nos encontramos con
una celda de valor 0,24 y color blanco, lo que, en relación a otros riesgos, nos dará una
valoración de riesgo poco relevante.
Impacto Bajo Medio Alto
Probabilidad 0,3 0,6 0,9
0,8 0,24 0,64 0,72
0,6 0,18 0,36 0,54
0,4 0,12 0,24 0,36
0,2 0,06 0,12 0,18
En función de los grados de importancia asignados a cada riesgo, el Plan de Res-

puesta recogerá actuaciones de un tipo u otro y con un grado de intensidad u otro.
Riesgos de alta probabilidad e impacto (áreas negras) requerirán análisis más detallados
y respuestas formales y bien elaboradas con indicadores de aviso bien claros.
La empresa puede clasificar un riesgo por separado para cada objetivo del proyecto
(plazo, coste…) y puede elaborar un análisis global para todo el proyecto de las opor-
tunidades y riesgos y su impacto en sus objetivos.
Esta priorización guía las respuestas a los riesgos centrándose en aquellos de impor-
tancia alta mientras que, como se ha comentado, los bajos se incluyen en una lista de
supervisión.
Gráficos jerárquicos (Hierarchical carts)

En el caso de que los riesgos se categoricen con más de dos parámetros, no es fácil
utilizar la matriz de probabilidad e impacto descrita en el punto anterior. En estos casos
es posible utilizar gráficos jerárquicos.
Dentro de este tipo de gráficos, el más útil de cara a ser utilizado en este proceso es
el gráfico de burbujas, que muestra los datos en tres dimensiones. En esta represen-
tación cada riesgo se muestra como una burbuja. Dos de los tres parámetros se repre-
sentan en los ejes X e Y, mientras que el tercero se representa con el tamaño de la
burbuja.
En el ejemplo mostrado a continuación, puede verse como el eje X representa la
Proximidad, el eje Y la Manejabilidad y el tamaño de la burbuja marca el Impacto del
riesgo.
En este ejemplo, no deberían ser tolerables los riesgos de alto impacto baja mane-
jabilidad y alta proximidad, es decir, los riesgos representados por burbujas grandes,
situados en la parte inferior derecha de la gráfica.
Generalmente el equipo del proyecto realiza reuniones de trabajo para realizar el
análisis cualitativo de los riesgos. En estas reuniones (workshops) se analiza uno a uno
cada riesgo y se debaten con el objetivo de determinar la probabilidad e impacto, cate-
gorización y priorización.
Además deberá ser identificado un dueño o responsable de cada riesgo. Este rol será
responsable de gestionar el riesgo, por lo que es un rol crucial para llevar a cabo una
correcta gestión de los riesgos del proyecto.
SALIDAS (OUTPUTS):
Como resultado de este proceso se actualizará el registro de riesgos con información

obtenida en este proceso: evaluaciones de la probabilidad e impacto, su prioridad, infor-
mación sobre su urgencia...
Actualización de documentos del proyecto (project documents updates)

Entre los documentos a actualizar está el registro de riesgos.
Además de la información ya incluida en la fase de identificación de riesgos –lista
de riesgos, sus posibles causas, categorización…– en este momento se está en disposición
de completar este registro con nueva información como:
Prioridades o clasificaciones de riesgos. Esta información se deducirá de la matriz de
probabilidad-impacto. El project manager, en función de las características del proyecto
y las posibilidades reales, priorizará unos riesgos sobre otros.
Riesgos agrupados por categorías. Esta agrupación puede revelar causas comunes a varios
riesgos o áreas del proyecto que requieran atención especial y establecer planes de res-
puesta coordinados.
Lista de riesgos que requieren atención particular. Si, por ejemplo, se descubren concen-
traciones de riesgos se pueden plantear medidas más efectivas y más racionales. También
puede ocurrir que riesgos con gran impacto y probabilidad afecten a áreas críticas que
requieran una respuesta específica, con una tecnología no suficientemente conocida en
la empresa, lo que lleve a externalizar el paquete de trabajo o el diseño de la tecnología
para su eliminación.
Riesgos con respuesta a corto plazo y largo plazo. Pueden agruparse para diseñar medidas
más detalladas para los primeros e ir planificando las correspondientes a los segundos.
Lista de supervisión de riesgos de baja prioridad. Aunque no requieran respuesta, deben
ser monitorizados puesto que esta matriz es dinámica y en un momento dado del pro-
yecto pueden saltar a otro nivel de importancia y prioridad. Por ello, se incluyen en esta
lista de supervisión (watchlist).
Además, fruto de la ejecución del proceso, pueden verse actualizados el Registro
de asunciones, el registro de incidencias y el informe de riesgos- que entre otra infor-
mación contendrá tendencias identificadas tras el análisis cualitativo.
3.10.4. Realizar el análisis cuantitativo de riesgos

Este proceso tiene por objetivo analizar numéricamente el efecto de los riesgos
identificados como relevantes en los objetivos globales del proyecto. El principal bene-
ficio de este proceso es que generará información cuantitativa del impacto del riesgo
que ayudará en la toma de decisiones sobre qué Plan de Respuesta seleccionar para
mitigar su impacto.
En algunos casos puede no ser posible ejecutar este proceso al faltar datos suficientes
para elaborar los modelos de análisis apropiados. Es el project manager quien debe eva-
luar esta situación y ver si es posible realizar este análisis cuantitativo de forma fiable.
Por lo tanto, y de acuerdo a A Guide to the Project Management Body of Knowledge
(PMBOK® Guide) – Sixth Edition, Project Management Institute, Inc., 2017, en este pro-
ceso se analizará numéricamente el efecto de los riesgos identificados sobre los objetivos
generales del proyecto para aquellos riesgos que han sido priorizados en el proceso de
análisis cualitativo. Para ello, se evalúa el impacto de los riesgos priorizados y se cuantifica
la exposición al riesgo del proyecto asignando probabilidades numéricas a cada riesgo y
sus impactos sobre los objetivos del proyecto.
Por tanto las actividades que comprende son:
• Definir el tipo de función de probabilidad que se va a asignar al parámetro
(normal, gamma…).
• Realizar análisis de sensibilidad para determinar los riesgos con mayor impacto.
• Decidir si el riesgo requiere la definición y planificación de una acción de res-
puesta.
• Determinar el riesgo global del proyecto.
• Cuantificar la probabilidad global de cumplir los objetivos del proyecto.
• Calcular el coste del riesgo mediante el análisis del valor esperado.
• Con estos resultados, cuantificar las reservas de contingencias y de gestión nece-
sarias.
• Actualizar las líneas de base del coste y plazo con las reservas de tiempo y coste.
El project manager, dependiendo de las características del proyecto, datos disponi-
bles… puede utilizar el análisis cualitativo, el análisis cuantitativo o ambos. Es importante
que, si se utiliza el cuantitativo, se trate de realizar de igual manera siempre que haya
un nuevo evento. De esta forma se podrá hacer un seguimiento general de los riesgos.
El project manager tendrá así una cuantificación numérica que respalde sus decisiones
y le permita comparar riesgos dentro de un mismo proyecto. Y, por supuesto, es muy
importante que se documente todo el proceso.
El proceso se repetirá:
• Tras planificar la respuesta a los riesgos: Las actividades que incluyan estos planes
se incorporan al alcance del trabajo como paquetes de trabajo o entregables.
Estas nuevas actividades afectarán al alcance, coste y tiempo.
• Durante la ejecución del proyecto: Una vez se conozcan los resultados del pro-
ceso de seguimiento y control de los riesgos se sabrá si realmente han tenido
efecto las medidas aplicadas y si el efecto ha sido esperado para, en caso negativo,
poner en marcha el plan alternativo (fallback plan).
Si bien el análisis cualitativo utiliza números, no debe confundirse con el análisis
cuantitativo. En el primero, detrás de cada cifra hay una evaluación subjetiva –el número
implica un nivel o un grado no una cantidad real– mientras que en el segundo hay una
evaluación numérica más objetiva. En el primero la probabilidad será baja, media o alta,
mientras que en el segundo será del 15%, 40%, 90%…
Este esquema ubica el proceso de análisis cuantitativo de riesgos dentro de su área
de conocimiento y su grupo de procesos dentro de las fases del proyecto:
En definitiva, los objetivos de este proceso serán, por tanto: analizar numéricamente
el efecto de los riesgos identificados sobre la totalidad de los objetivos del proyecto,
determinar qué riesgos van a necesitar una respuesta, determinar el riesgo global del
proyecto, determinar la probabilidad cuantificada de lograr los objetivos, crear objetivos
de costes, alcance y calendario realistas alcanzables, determinar las reservas de costes y
calendario e identificar riesgos que requieran la mayor atención.
En el esquema siguiente se sintetiza el proceso de identificación de riesgos que
pasaremos a desarrollar a continuación.
Como se ha comentado, en ISO21500 existe un proceso denominado «Evaluar los riesgos»

que engloba los dos procesos similares – «Realizar el análisis cualitativo de riesgos» y «Realizar
el análisis cuantitativo de riesgos» de PMBOK–.
ANÁLISIS CUANTITATIVO DE RIESGOS (CUANTITATIVE RISK

ANALYSIS)
Mediante este proceso se cuantifican los posibles resultados del proyecto y sus
probabilidades, se determina la probabilidad de lograr los objetivos del proyecto y se
identifican los riesgos que requieren un Plan de Respuesta o la creación de una reserva
(de tiempo o coste) de contingencia.
ENTRADAS (INPUTS):
Para realizar el análisis cuantitativo de los riesgos se tomará como información de

base el Plan de Gestión de Riesgos –donde están las guías, métodos y herramientas a
utilizar en el análisis cuantitativo–, las líneas base de alcance, tiempo y costes –donde se
define cómo establecer y gestionar las reservas de riesgos–, documentos del proyecto
como el registro de riesgos –como punto de referencia donde encontrar toda la infor-
mación actualizada de riesgos–, los factores ambientales de la empresa –estudios secto-
riales y bases de datos disponibles...– y los activos de los procesos de la organización –
con información histórica y lecciones aprendidas de proyectos similares–.
Plan de dirección del proyecto (Project management plan)

Plan de Gestión de Riesgos (risk management plan)
Plan subsidiario del Plan de Dirección del Proyecto que define cómo se va a orga-
nizar y llevar a cabo el proceso de gestión de los riesgos del proyecto, en concreto cómo
se va a realizar, si es que se va a realizar, el análisis cuantitativo de riesgos.

Define el punto de partida a partir del cual los riesgos pueden incidir con su impacto
teórico en el alcance en caso de materializarse.
Línea base de cronograma (Schedule baseline)

teórico en el cronograma en caso de materializarse. Incluye las reservas temporales aso-
ciadas a los riesgos.
Línea base de coste (Cost baseline)

teórico en los costes en caso de materializarse. Incluye las reservas de costes asociadas a
los riesgos.

Registro de asunciones (Assumption log)
Contiene las asunciones y restricciones del proyecto. El registro de asunciones es
usado para identificar, gestionar y monitorizar las principales asunciones y restricciones
que pudieran afectar al proyecto. Las asunciones y restricciones pueden ser modeladas
durante el análisis cuantitativo de los riesgos.
Base de estimaciones (Basis of estimates)

Si han sido utilizadas bases de estimaciones para estimar las duraciones del proyecto
serán entrada en este proceso ya que la información sobre cómo se han realizado las
estimaciones será útil para analizar cuantitativamente los riesgos derivados del uso de las
mismas.
Estimaciones de coste (Cost estimates)

Proporcionan un punto de partida a partir del cual se deberán evaluar las variaciones
de coste.
Previsión de costes (Cost forecasts)

Variables utilizadas en la gestión de costes pueden ser utilizadas para comprarlas con
los resultados del análisis cuantitativo de los riesgos relacionados con los costes. De ese
modo se podrá determinar el nivel de confianza asociado al cumplimiento de los obje-
tivos económicos del proyecto.
Estimación de duración (Duration estimates)

de tiempo.
Lista de hitos (Milestone list)

Los hitos marcados en el proyecto determinan puntos de control en los que se puede
comparar los resultados obtenidos respecto a la planificación realizada. De ese modo se
podrá determinar el nivel de confianza asociado al cumplimiento de los objetivos tem-
porales del proyecto.
Requerimientos de recursos (Resource requierments)

de recursos utilizados en el proyecto.

Comprende la lista de riesgos, la lista de potenciales respuestas al riesgo –cuando
una primera respuesta se identifica a la vez que el riesgo–, las raíces de los riesgos y la
actualización de la lista de categorías de riesgos.
Informe de riesgos (Risk report)

Describe las fuentes de los riesgos y el estado actual del riesgo global del proyecto.
Previsión de cronograma (Schedule forecasts)

Será posible comparar la previsión del cronograma con los resultados derivados del
análisis cuantitativo del riesgo de modo que se pueda determinar el nivel de confianza
asociado al cumplimento de los objetivos temporales del proyecto.
Factores ambientales de la empresa (Entrerprise environmental factors)

Se tendrán en cuenta los estudios de riesgos en el sector publicados o las bases de
datos de riesgos que hayan sido publicadas o puedan adquirirse.

• Información suficientemente detallada del proyecto, de lo que hacen otras com-
pañías, de artículos y toda clase de información que ayude a cuantificar los ries-
gos.
• Información histórica de proyectos similares que suministrarán información
sobre cómo se realizó la evaluación cuantitativa de los riesgos.
• Lecciones aprendidas de proyectos anteriores que ayuden a mejor cuantificar los
riesgos del proyecto.
• Procedimientos, políticas y formatos de la organización que proporcionan una
forma o norma estandarizada para evaluar cuantitativamente los riesgos en la
organización.
Para evaluar cuantitativamente el impacto de los riesgos en el proyecto se debe

recoger información procedente de experiencias previas, proyectos anteriores, entre-
vistas con expertos en los temas que permita cuantificar la probabilidad y el impacto de
los riesgos. Se debe documentar la razón detrás de los valores e intervalos de confianza
del impacto, las suposiciones realizadas en su cálculo y las distribuciones de probabilidad
asignadas.
Se podrán también, dependiendo de la información existente, el tiempo y presu-
puesto disponible y la relevancia de los riesgos en el proyecto, utilizar diferentes técnicas
de modelización y análisis cuantitativo de riesgos: análisis de sensibilidad –para deter-
minar qué riesgos tienen un mayor potencial en el proyecto y cómo afecta a los objetivos
del proyecto una variación unitaria de la variable riesgo–, el análisis del valor monetario
esperado –calculado como la suma de los productos de la probabilidad por el impacto
de cada uno de los riesgos– o la modelización y simulación mediante la técnica de Monte
Carlo.

Se realizarán consultas a expertos en la materia o externos a la organización ya en
áreas técnicas como la ingeniería o la tecnología ya en áreas como la estadística o las
técnicas de estimación.
Es recomendable que el grupo de expertos que participen tengan conocimiento
especializado en:
• Traducción de la información sobre los riesgos del proyecto en valores numé-
ricos para el análisis de riesgo cuantitativo.
• Seleccionar el método de representación de la incertidumbre más apropiada para
modelar riesgos.
• Seleccionar las técnicas y herramientas de modelización apropiadas para el pro-

yecto.
• Interpretar adecuadamente los resultados del análisis de riesgo cuantitativo,
obteniendo conclusiones sobre el mismo y trasladándolas al Project manager.
Recopilación de datos (Data gathering)

En las entrevistas con las partes interesadas, miembros del equipo y expertos en el
sector, se trata de, a partir de la experiencia en proyectos anteriores y con tecnologías
similares, poder establecer valores cuantitativos tanto para el impacto como para la pro-
babilidad del evento de riesgo.
Dependiendo de la distribución de probabilidad a utilizar o el parámetro estadístico
elegido, en las entrevistas se tratará de caracterizar y dar valores a unos u otros (medias,
valores optimista, pesimista, probable, varianza, tipo de distribución de probabilidad más

adecuada). Esta técnica se combina con la siguiente.
Como en otros casos, es tan importante la estimación numérica como la documen-
tación de las asunciones, justificaciones y reflexiones que se realicen, porque formarán
parte del análisis posterior y serán de gran utilidad en futuros proyectos.

Representaciones de incertidumbre (Representations of Uncertainty)

Las distribuciones más habituales en análisis cuantitativo de riesgos son las distribu-
ciones Beta, Normal y Triangular y suelen utilizarse para ajustar una distribución de
probabilidad para los valores del coste y tiempo.
Las distribuciones triangulares, de acuerdo al método PERT, se basan en dar tres
valores para la duración, el coste o, en este caso, el impacto o la probabilidad:
• El valor más pesimista –si las cosas salen mal–.
• El valor más optimista –si todo sale perfectamente bien–.
• El valor más probable –el más habitual, el que suele ocurrir–.
Como se vio, del cálculo para el caso de la duración de las actividades, con estos
tres valores, se obtiene un valor llamado «Pert promedio ponderado» (Media) –que
supone que la distribución de estos valores sigue una distribución beta–:
Pert promedio ponderado (Media) = (Optimista + 4*más probable +pesimista)/6

De esta manera para cada una de las actividades, especialmente del camino crítico,
se calcula su valor de duración o coste promedio. Su desviación típica se calcula como:
Desviación típica = (optimista-pesimista)/6
De esta manera como por las leyes generales de la estadística la suma de un número
suficiente de variables beta forma una distribución normal, nos encontramos con que la
probabilidad, impacto, duración…final del proyecto seguirá una distribución normal
de:
• Media: la suma de los valores PERT promedios ponderados de todas las tareas.
• Desviación típica: la raíz cuadrada de las sumas de los cuadrados de las desvia-
ciones típicas de cada tarea.
Con esta información, y como ya se explicó al tratar la estimación de la duración
de actividades, se pueden obtener las probabilidades de que sucedan diferentes riesgos
en diferentes intervalos de confianza con sus probabilidades asociadas.

Simulaciones (Simulations)
El análisis cuantitativo de riesgos utiliza un modelo que simula los efectos combi-
nados de los riesgos individuales del proyecto para poder así evaluar su impacto potencial
sobre el proyecto. Las simulaciones se realizan habitualmente usando la técnica de
Monte Carlo.
La simulación de Monte Carlo consiste, básicamente, en generar una serie de valores
aleatorios de una variable en función de la distribución probabilística que se le asigne.
Mediante este método se generaría una probabilidad general para el coste total o el plazo
final del proyecto. La simulación de Monte Carlo utiliza el diagrama de red y hace una
simulación para estimar los resultados de coste y calendario del proyecto.
Este método evalúa el proyecto dando, entre otras, la probabilidad de que:
• Se complete el proyecto antes de un día concreto o con un coste menor a uno
determinado.
• La duración del tiempo o el coste previsto de cualquier tarea crítica sea menor
a la prevista.
• Una tarea pueda estar en el camino crítico.
Este método de simulación:
• Tiene en cuenta la convergencia de caminos (path convergence) que aumenta
el riesgo.
• Traslada las incertidumbres en los impactos al proyecto en su conjunto.
• Se puede usar para evaluar los impactos en el coste y el cronograma.
Debido a la complejidad de los cálculos se utilizan programas de ordenador para
hacer los cálculos que acaban resultando en una distribución de probabilidades para los
diferentes valores de tiempo y coste del proyecto.
Análisis de sensibilidad (Sensitivity analysis)

Es una técnica cuantitativa que nos permite analizar el impacto potencial de los
eventos de riesgo analizando cómo variaciones de un determinado parámetro afectan al
coste o plazo total del proyecto dejando el resto de variables fijas.
Permiten conocer los riesgos con un mayor impacto potencial en el proyecto o
dicho de otro modo, los riesgos a los que es más sensible el proyecto –una variación en
el riesgo produce un aumento del impacto superior–. El impacto sobre un proyecto
puede ser muy sensible a pequeñas variaciones de una variable –una pequeña variación
porcentual provoca un gran retraso en un proyecto– o, por el contrario, poco sensibles
–el retraso o el aumento de coste de una variable importante afecta muy poco al pro-
yecto–.
Estos análisis permiten identificar aquellas variables, parámetros, eventos de riesgo
a los que el proyecto es altamente sensible y que puede verse severamente afectado por
su variación u ocurrencia. De esta manera, el project manager se concentrará en estos

riesgos para los que elaborará planes detallados y bien analizados de respuesta.
Análisis mediante árbol de decisiones (Decision tree analysis)

El árbol de decisiones es un diagrama de todas las acciones, eventos y resultados
posibles que pueden ocurrir para un evento concreto. Es conveniente utilizarlo cuando
se deben tomar decisiones en distintos puntos del proyecto a lo largo de un período
largo de tiempo.
Se estructura como un árbol que describe:
• Una situación y las alternativas que se está analizando.
• Las implicaciones de cada una de ellas.
• Las probabilidades de ocurrencia.
• Los posibles escenarios finales.
Presenta el coste de cada opción, las probabilidades de cada escenario posible y los
beneficios de cada camino alternativo. Al resolverlo, se obtiene el valor esperado para
cada alternativa tras cuantificar todas las oportunidades (ingresos o ahorros) y amenazas
(pérdidas o sobrecostes).
Suponemos que se está tomando la decisión de lanzar un nuevo modelo de vehículo
de gama alta con una inversión de 8.000.000 euros frente a la de proseguir con el exis-
tente que, con una nueva campaña de marketing (inversión de 1.000.000 euros), se han
estimado las probabilidades de aumentar las ventas y de obtener los beneficios que se
indican en la figura siguiente:
En este caso, como estamos hablando de beneficios, el mayor valor esperado corres-
ponde a lanzar el nuevo modelo.
En el ejemplo siguiente, enfocado a riesgos, se trataría de analizar el valor esperado
en la compra de una turbina más o menos potente conociendo las probabilidades de
vientos altos o bajos y los costes derivados de esos vientos a la turbina:

Manual para Project Managers Cómo Gestionar Proyec... - (PG 42 - 392)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual para Project Managers Cómo Gestionar Proyec... - (PG 42 - 392)

Cargado por

Copyright:

Formatos disponibles

40 Introducción

Su identificación no es inmediata ni estática en la vida del proyecto, ya que pueden

Es muy importante identificar a todos los interesados de un proyecto porque si se

Coste (Cost) El proyecto no deberá sobrepasar el coste aprobado.

Recursos (Resources) El proyecto tiene recursos humanos y materiales limitados.

Calidad (Quality) El proyecto debe tener los requisitos de calidad acordados.

Riesgo (Risk) Obstáculos inesperados pueden dar al traste con el proyecto.

La gobernanza de los proyectos (Project Governance)

1.2.4.2. La influencia del equipo de proyecto

1.2.4.3. El ciclo de vida del proyecto

Ciclo de vida del proyecto (Project Life Cycle)

organización y preparación, ejecución del trabajo y cierre.

Proyecto con varias fases

Dirección y gestión del proyecto a lo largo de su ciclo de vida

Relaciones entre fases

son bajos y todavía hay pocas personas asignadas al proyecto.

Tipos de ciclos de vida de proyectos

esfuerzo a la planificación del mismo y centrándose en la priorización del trabajo a

Ciclo de vida iterativo e incremental

Puerta de una fase (Phase gate)

1.2.4.4. Los condicionantes de un proyecto según la ISO21500

ISO21500 define de forma integrada el entorno de la gestión de proyectos en una orga-

Tipos de ciclos de vida de proyectos

Tratamos brevemente los diferentes conceptos que conforman el esquema:

La evaluación de oportunidades y el inicio de proyectos:

Materializar los beneficios (transición del resultado del proyecto a operaciones):

La responsabilidad de mantener una adecuada y efectiva gobernanza de proyectos

1.2.5. Qué es la dirección de proyectos

Así, los elementos de la parte superior (misión, visión, objetivos estratégicos…)

Dirección de Proyectos (Project management)

ISO21500 define la gestión de proyectos como la aplicación de métodos, herramientas,

Gestión de Programas (Program management)

De acuerdo a la ISO21500 un programa es un conjunto de proyectos y otras actividades

Gestión de Carteras (Portfolio management)

De acuerdo a la ISO21500 una cartera o portfolio de proyectos es un conjunto de programas

Oficina de Gestión de Proyectos (Project Management Office, PMO)

mentan al project manager con sugerencias sobre planes de aceleración, asignaciones de

1.2.6. El valor del negocio (Business value)

El Project manager debe asegurar que el enfoque del proyecto va encaminado a

Caso de negocio del proyecto (Project business case)

• Breve descripción del alcance.

Plan de gestión de beneficios del proyecto (Project benefits management plan)

• Alineamiento estratégico, definiendo cómo se alinean los beneficios del

Medición de éxito del proyecto (Project success measures)

1.2.7. El project manager: funciones y habilidades

• Gestionar los cambios en el proyecto.

Habilidades de organización y planificación

actualizada. Asimismo organizará y planificará reuniones, coordinará equipos, gestionará

Habilidades para gestionar costes y presupuestos

Habilidades para gestionar conflictos

Habilidades para negociar y convencer

Habilidades para hacer equipo y motivarlo

Habilidades para generar confianza

1.2.8. Guía del PMBOK®

1.2.9. Grupos de procesos en project management

ISO21500 divide los procesos en tres categorías:

de la gestión de proyectos, tienen como resultado la creación de un producto, servicio o

Los procesos de gestión de proyectos

ISO21500 los agrupa igualmente en cinco grupos denominados de inicio, de planificación,

Esquema general de grupos de procesos

Al proceso de avance se le han añadido tres relaciones de retroalimentación (feed-

• Durante la ejecución se supervisan y controlan los avances y se realizan los

Grupo de procesos de inicio (Initiating processes)