Gestion de Proyectos

MANUAL
GESTIÓN DE
PROYECTOS
European Open Business School

MANUAL GESTIÓN DE PROYECTOS
INDICE
1. ACTA DE CONSTITUCIÓN E IDENTIFICACIÓN DE INTERESADOS ............................................ 4

1.1. Desarrollar el Acta de Constitución del proyecto ....................................................... 21
1.2. Identificar a los Interesados ........................................................................................ 25
1.3. Planificar la Gestión de los Interesados ...................................................................... 29
2. CREACIÓN DE LA EDT Y EL DICCIONARIO DE LA EDT ........................................................... 32
2.1. Planificar la Gestión del Alcance ................................................................................. 43
2.2. Recopilar Requisitos .................................................................................................... 45
2.3. Definir el Alcance ........................................................................................................ 54
2.4. Crear la EDT/WBS ........................................................................................................ 57
3. Creación de la obs y la ram del proyecto ............................................................................ 62
3.1. Planificar la Gestión de Recursos Humanos ................................................................ 86
4. Comportamiento del grupo................................................................................................. 91
4.1. Planificar la Gestión del Cronograma ........................................................................ 106
4.2. Definir las Actividades ............................................................................................... 109
4.3. Secuenciar las Actividades ........................................................................................ 112
4.4. Estimar los Recursos de las Actividades .................................................................... 116
4.5. Estimar la Duración de las Actividades ..................................................................... 119
4.6. Desarrollar el Cronograma ........................................................................................ 126
5. Creación de la curva s y del presupuesto .......................................................................... 143
5.1. Planificar la Gestión de Costes .................................................................................. 161
5.2. Estimar los Costes ..................................................................................................... 164
5.3. Determinar el Presupuesto ....................................................................................... 171
6. Creación y evaluación de los riesgos ................................................................................. 175
6.1. Planificar la Gestión de Riesgos................................................................................. 188
6.2. Identificar los Riesgos................................................................................................ 192
6.3. Realizar el Análisis Cualitativo de Riesgos ................................................................. 200
6.4. Realizar el Análisis Cuantitativo de Riesgos .............................................................. 203
6.5. Planificar la Respuesta a los Riesgos ......................................................................... 213
European Open Business School 2

7. CONTROL DE CAMBIOS Y ANALISIS DE IMPACTO ............................................................. 219

7.1. Dirigir y Gestionar el Trabajo del Proyecto ............................................................... 221
7.2. Realizar el Control Integrado de Cambios ................................................................. 226
8. CONTROL DEL CRONOGRAMA Y LOS COSTES ................................................................... 230
8.1. Controlar el Cronograma........................................................................................... 244
8.2. CONTROLAR LOS COSTES .......................................................................................... 249
9. SEGUIMIENTO Y EVALUACIÓN DE RIESGOS ...................................................................... 253
9.1. Controlar los Riesgos ................................................................................................. 256
10. INFORME DE ESTADO DEL PROYECTO........................................................................... 259
10.1. Monitorizar y Controlar el Trabajo del Proyecto .................................................. 260
11. CIERRE ORDENADO ....................................................................................................... 266
11.1. Grupo de Procesos de Cierre ................................................................................. 269
11.2. Cerrar el Proyecto o Fase ...................................................................................... 272
11.3. Cerrar las Adquisiciones ........................................................................................ 274
12. LECCIONES APRENDIDAS Y GESTION DEL CONOCIMIENTO .......................................... 276
12.1. La Guía del PMBOK® .............................................................................................. 277
12.2. Terminología común en Dirección de Proyectos .................................................. 286

1. ACTA DE CONSTITUCIÓN E IDENTIFICACIÓN DE

INTERESADOS
La Gestión de la Integración del Proyecto incluye los procesos y actividades

necesarios para identificar, definir, combinar, unificar y coordinar los diversos procesos
y actividades de dirección del proyecto. La gestión de un proyecto se estructura en
múltiples procesos, pero los objetivos se consiguen de forma integrada, y el equipo de
dirección del proyecto decide cómo implementar cada proceso teniendo en cuenta las
interrelaciones (p. ej., los costes de un plan de contingencia se originan en el área de
riesgos, hay riesgos derivados de la adquisición de personal, etc.).
El significado de la palabra “integración” en Gestión de Proyectos
La palabra “integración” tiene más de un significado en gestión de proyectos.

La Guía del PMBOK® incluye en el área de conocimiento de gestión de la integración
del proyecto los procesos dirigidos principalmente a integrar la información proveniente
de las otras áreas, generalmente con el objetivo de unificar documentos. Pensemos,
por ejemplo, en el grupo de procesos de inicio, todo el debate que ha tenido lugar en la
organización ejecutora con el fin de decidir si el proyecto está alineado con la
estrategia, es oportuno, es más rentable que otras iniciativas posibles, etc., habiendo
implicado a distintos expertos, se reúne en un sencillo documento llamado "acta de
constitución" que sirve para dejar constancia por escrito de que el proyecto ha sido
aprobado por la organización y hay un patrocinador a quien dirigirse si se necesitan
más explicaciones sobre por qué la organización está dedicando recursos a este
proyecto. Pues bien, este sencillo documento, que debe ser breve, es un resumen
ejecutivo sobre la información relevante de otras áreas de gestión, como por ejemplo:
 Gestión del alcance: ¿Cuáles son los principales requisitos? ¿Qué entregables
hay que producir? ¿La organización está capacitada para generar el producto
final?
 Gestión de los tiempos: ¿Se cumplirán los hitos clave? ¿El proyecto durará
demasiado?
 Gestión de costes: ¿Supondría el proyecto un coste inasumible para la
organización ejecutora? ¿El cliente podrá financiar apropiadamente el
proyecto?
 Gestión de recursos humanos: ¿Contará la organización ejecutora con el
personal capacitado cuando sea necesario, trabajando con buen desempeño a
lo largo del proyecto?
 Gestión de riesgos: ¿La organización puede asumir el riesgo que supondría
ejecutar este proyecto?

 Gestión de adquisiciones: En lo que respecta a los trabajos a subcontratar,

¿existen proveedores cualificados a precio asumible? ¿La organización tiene
capacidad para administrar los contratos? ¿Se dispone de la cobertura legal
necesaria para ir a juicio, en el peor de los casos?
 Gestión de los interesados: ¿Qué expectativas de qué interesados clave debe
cumplir el proyecto para finalizar con éxito? ¿Se identifican interesados de alto
poder contrarios al proyecto?
En la práctica, la palabra integración puede tener otras acepciones, como son

las siguientes:
 El director de proyectos ejerce un rol integrador (centralizador, punto único de

contacto): Los interesados preguntan al Director del Proyecto, no a los
miembros del equipo, ya que el Director del Proyecto tiene una visión integral
de todo el proyecto (objetivos, interesados, expectativas, planes, actividades,
entregables, documentos, incertidumbres, incidentes, situación, pronósticos,
etc.).
 El proyecto ha de integrarse en el contexto organizativo (de la organización
ejecutora y/o de la organización solicitante): Esto significa, por ejemplo, vigilar
el alineamiento estratégico durante el proyecto, suavizar la transición entre el
cierre de una fase y el inicio de la siguiente, transferir los productos del
proyecto a operaciones, etc.
El inicio de un proyecto en una organización
La gestión del proyecto comienza desde antes de su aprobación, cuando es tan

solo una idea. Alguien externo al equipo del proyecto propone el proyecto. Si después
de analizar esta demanda, el proyecto llega a aprobarse, esta figura ejercerá el papel
de patrocinador del proyecto. Si a lo largo de la ejecución del proyecto hay que tomar
decisiones fundamentales, como por ejemplo la de aceptar algún cambio que
contradice la razón por la que se aprobó el proyecto, o afecta gravemente a los
objetivos, o si ha de cancelarse anticipadamente por cualquier motivo, etc., este tipo
de decisiones fundamentales debe aprobarlas siempre el patrocinador del proyecto.
Para el Director del Proyecto, el patrocinador es uno de los interesados más
importantes, si no el que más, pues es quien defiende, dentro de la organización
ejecutora, que el proyecto ha de consumir los recursos previstos en lugar de dedicarse
a otra iniciativa, operación o proyecto. A veces será un alto directivo, un gerente
funcional o responsable de línea de negocio, un comercial que ha vendido el proyecto
al cliente, etc.
Según la Guía del PMBOK®, los proyectos responden a una necesidad de la

organización, de varios tipos:

Tipo de Necesidad Ejemplo

 Demanda de mercado  Una compañía de automoción que autoriza un proyecto para construir más automóviles de bajo
consumo en respuesta a la escasez de combustible.
 Necesidad de la organización  Debido a los altos costes generales una compañía puede combinar funciones del personal y
racionalizar procesos para reducir costes.
 Solicitud de un cliente  Una compañía eléctrica que autoriza un proyecto para construir una nueva subestación a fin de
abastecer un nuevo parque industrial.
 Avance tecnológico  Una compañía aérea que autoriza un nuevo proyecto para desarrollar el billete electrónico y sustituir
los billetes en papel, sobre la base de los avances tecnológicos.
 Requisito legal  Un fabricante de pinturas que autoriza un proyecto para establecer pautas sobre la manipulación de
materiales tóxicos.
 Impacto ecológico  Una compañía que emprende un proyecto para disminuir su nivel de emisión de gases
contaminantes.
 Necesidad social  Una organización no gubernamental en un país en vías de desarrollo que autoriza un proyecto para
dotar de sistemas de agua potable, baños y educación sanitaria a comunidades que padecen altos
índices de cólera.
Esta información causal puede encontrarse en un documento como es un plan

de negocio, un acuerdo o contrato con un tercero, una orden de trabajo del proyecto,
una petición de propuesta, etc. A veces falta este tipo de información y entonces es
necesario analizar con mayor detenimiento la necesidad y sus orígenes.
La decisión de lanzar un proyecto nunca ha de tomarse a la ligera. Antes de

comprometer recursos y presupuesto, es preciso un análisis sobre si el proyecto está
justificado porque resulta alineado con la estrategia, oportuno, conveniente, mejor que
otras iniciativas posibles, etc. Este debate organizativo, en el que deben participar
muchos expertos en la materia, puede concluir con la aprobación del proyecto, o bien
con su rechazo o aplazamiento. Es buena práctica que la organización dedique
recursos a esta fase de justificación y aprobación. Si el Director del Proyecto participa
en esta fase, entonces podrá aportar su trabajo y conocimientos de gestión de
proyectos, que servirán para identificar los principales entregables, los principales
riesgos, realizar estimaciones de alto nivel, hacer participar a los expertos, coordinar
estos esfuerzos, organizar la documentación inicial, etc.
Si el proyecto finalmente se aprueba, debe quedar constancia escrita. Este

documento es propiedad del patrocinador y se le denomina acta de constitución del
proyecto.
En las organizaciones dedicadas a vender proyectos, como las empresas de

consultoría, esta fase de inicio consiste en responder competitivamente a la solicitud
del cliente con una propuesta de proyecto. Si la empresa de consultoría resulta
adjudicataria, se procede a la negociación y firma de un contrato.
Cuando un proyecto se subdivide en varias fases, cada una de ellas podrá

gestionarse como un proyecto. Si al comenzar cada fase se vuelven a repetir los
procesos de inicio, en mayor o menor medida, esto permitirá:

 Mantener el proyecto centrado en la necesidad de negocio.

 Verificar los criterios de éxito.
 Revisar la influencia y los objetivos de los interesados.
Valoración financiera de proyectos
Desde que alguien tiene la idea del producto servicio o resultado final (p.ej.: la
nueva versión del iPhone), hasta que se transfiere a operaciones o se explota (p.ej.: se
produce en las fábricas, se vende en las tiendas), ocurren fundamentalmente tres tipos
de gestión:
 Gestión de la Demanda: La iniciativa es justificada, priorizada, aprobada, etc.;

 Gestión de Proyectos: Se decide si merece la pena ejecutar el proyecto o la
fase, se aprueba, planifica, ejecuta, controla, se realiza la transferencia a la
organización y se cierra el proyecto; y
 Gestión de Operaciones: Se asume la operación del producto, servicio, o
resultado, por las unidades correspondientes de la organización, se
especializan los recursos necesarios y se mantiene en funcionamiento hasta su
retirada.
Como puede apreciarse en la figura, cada disciplina de gestión está

diferenciada y también relacionada con las otras:
Volvamos al inicio del proyecto. La Guía del PMBOK® no pretende

estandarizar cómo realizar un plan de negocio, pero sí debemos conocer un dato
fundamental que suele incluirse en un plan de negocio: el indicador de valoración
financiera del proyecto. Si hay varios proyectos posibles pero no hay recursos para
ejecutar todos, un director de proyectos debe saber cómo su proyecto será valorado
financieramente y comparado con los demás.

Cuando el responsable del departamento financiero diga que nuestro proyecto

no ha sido aprobado porque tenía un TIR, un VAN, o un payback peores que otro
proyecto, debemos saber cómo se han calculado estos indicadores.
El primer concepto a tener en cuenta para valorar financieramente un proyecto

es el de flujo de caja (cashflow, en inglés). Los flujos de caja pueden ser negativos, si
son pagos, o positivos, si son cobros. Contablemente se distinguen varios tipos de
pagos (compras, gastos, costes) y cobros (ingresos, ventas). Si representamos los
flujos de caja en una línea de tiempo, comprobaremos que durante la fase de proyecto
suele haber exclusivamente flujos negativos, y a partir de que el producto del proyecto
se pasa a producción, aparecen flujos positivos que hacen que el proyecto acabe
siendo económicamente rentable.
El siguiente concepto importante es que el dinero crece con el tiempo. O lo que

es lo mismo: El dinero en el futuro es menos dinero hoy (p.ej.: 100.000€ dentro de un
año, a una tasa de interés del 10%, es igual que 90.910€ hoy, porque si se invierte ese
dinero en un banco, a ese interés, se obtendrán 100.000€ dentro de un año). Para un
inversor, 1.000€ de hoy tienen el mismo valor que 1.611€ dentro de 5 años, a un
interés del 10%.

Para comparar económicamente dos cantidades en distintos periodos,

debemos calcular el valor actual de las mismas. Para “retrotraer” el dinero n períodos,
a una tasa de interés i, hay que dividir por (1+i)^n. Por ejemplo, para “retrotraer”
1.000€ dentro de 5 años a dinero de hoy, a una tasa de interés del 10% anual, hay que
dividir por (1+10%)^5. Es decir, para un inversor, 1.000€ dentro de 5 años es lo mismo
que 621€ de hoy, porque si los invierte a un interés del 10% anual recibirá 1.000€ en 5
años.
Si tenemos varios flujos de caja, positivos o negativos, se calcula el valor actual

neto. En Microsoft Excel, versión en español, la fórmula del valor actual neto es VNA.
En la figura puede verse un ejemplo: Si el proyecto cuesta 500€ en el periodo 0, y se
obtiene un ingreso en 5 años de 2.000€, entonces el valor actual neto de este proyecto
es de 742€.
Ejercicio 1. Usted tiene un local y se plantea 2 opciones: 1) Si lo vende te

pagarán 50.000€ y 2) Si lo acondiciona como restaurante invirtiendo 300.000€ podrá
venderlo dentro de 1 año por 400.000€. Si la tasa de descuento fuera del 5%, ¿qué
decisión tomaría?
Solución:
Es recomendable invertir, ya que:
- VAN1 = 50
- VAN2 = -300 + 400/1,05 = 80,1

Ejercicio 2. ¿Y si la venta por 400k€ no es segura? ¿Y si tiene tanto riesgo

como una inversión en bolsa, que ofrece un posible 15% de retorno?
Solución:
Ya no es recomendable invertir:
- VAN1 = 50
- VAN2 = -300 + 400/1,15 = 47,8
Otro indicador muy utilizado en la valoración financiera de proyectos es la Tasa

Interna de Retorno (TIR): La TIR en n periodos es la tasa de interés para tener VAN=0
en n periodos. Para comprender bien este indicador, consideremos por ejemplo la
siguiente serie de flujos de caja anotados en una hoja de cálculo en Microsoft Excel:
A un interés del 5% en cada periodo, Excel nos permite calcular el VAN=892€.
Si el interés fuera del 10%, VAN=433€.

¿Y si el interés fuera del 16%? Entonces ocurre que VAN=0.
Gráficamente podríamos construir la curva del

VAN frente al interés. En el punto en que el VAN=0, el
interés es la TIR. En el ejemplo, a un interés del 16%, el
valor actual de los ingresos es igual al valor actual de los
pagos.
En general, un proyecto con un TIR de más de un

15% generalmente se considera atractivo porque produce
mayor desempeño que invertir en renta variable.
En las empresas, suele conocerse el Promedio Ponderado del Coste de

Capital, también llamada tasa de oportunidad, o tasa k de descuento (en inglés se dice
Weighted Average Cost of Capital –WACC), que es el coste promedio al que se paga
a los acreedores. Las empresas normalmente comparan la TIR con la tasa de
oportunidad (WACC). El VAN a un interés igual al WACC es el valor del proyecto al
interés que cuesta financiarlo. Por lo tanto, si TIR<WACC, entonces el proyecto
destruye valor en la empresa.
Cuando se trata de decidir un proyecto frente a otro, se escoge el de mayor

TIR. Típicamente, a mayor TIR, mayor VAN. En el ejemplo a continuación, se elegiría
el proyecto A porque ofrece una TIR del 31%, mayor que la TIR del proyecto B, de un
16%:

Otro indicador que puede tenerse en cuenta al evaluar un proyecto es el

payback o plazo de recuperación. El payback es el periodo de tiempo en el cual se
recupera la inversión inicial.
Ejercicio 3. Una empresa está evaluando un proyecto cuyos flujos de caja son:
Año 0=-200.000€; Año 1=100.000€; Año 2=200.000€; Año 3=400.000€; Año
4=300.000€. Calcular el plazo de recuperación o payback.
Solución:
- Suponiendo que los flujos de caja se obtienen al final del periodo, el payback sería
de 1,5 años, ya que se igualarían los pagos (200.000€ en año 0) con los ingresos
(100.000€ en año 1 más 100.000€ en el primer semestre del segundo año).
Por último, otro indicador financiero utilizado para valorar proyectos es el punto de
equilibrio. Corresponde al punto en el cual los gastos y los ingresos son equivalentes.
Permite determinar el número mínimo de unidades a vender, a partir de las cuales se
genera ganancia. Al igual que ocurre con el payback, este indicador también ignora
conceptos tales como el valor del dinero en el tiempo, el coste de la deuda o el coste
de oportunidad.
Para calcular el punto de equilibrio, hay que despejar n de esta ecuación:
Venta por Unidad * n = Coste Fijo + Coste Variable por Unidad * n

Ejercicio 4. Supongamos un restaurante con capacidad de 20 mesas, y cada

mesa con capacidad para 4 clientes. Las ventas medias mensuales son de 30.000€.
La ocupación media mensual es de 300 mesas. El coste fijo de la instalación es de
5.000€ al mes y el coste variable ha alcanzado los 18.000€. Calcular el punto de
equilibrio.
Solución:
 Coste Variable por mesa = 18000 / 300 = 60€

 Venta por mesa = 30000 / 300 = 100€
 100 * n = 5000 + 60 * n
 n = 125
 Punto de equilibrio = 125 mesas (el mes que se ocupan más de 125 mesas, el
restaurante tiene ganancias
Por último, otro indicador muy utilizado para evaluar proyectos, especialmente
en ciencias sociales, es el ratio beneficio-coste (en inglés Benefit Cost Ratio –BCR),
que se calcula como el beneficio del proyecto dividido entre el coste. Si BCR es mayor
que 1 entonces los beneficios son superiores a los costes
Ejercicio 5. Supongamos los siguientes flujos de caja de un proyecto, en una

empresa que tiene una tasa de oportunidad del 7%. Calcular el ratio beneficio-coste
descontado para evaluar si el proyecto es rentable.
Solución:
 Coste = 44500000+VNA(7%;1700000;1700000;1700000;1700000;1700000) =
51.470.336€
 Beneficio = VNA(7%;7500000;7500000;15000000;15000000;15000000) =
47.942.825€
 BCR = 47942825 / 51470336 = 0,93 (el proyecto no saldría rentable: es
deficitario)

En resumen, existen algunos modelos económicos bien conocidos para

cuantificar el retorno financiero de un proyecto, entre ellos:
 Valor Actual Neto VAN (Net Present Value NPV): Valor presente de un
determinado número de flujos de caja futuros, originados por una inversión. Se
escoge el proyecto que tenga mayor VAN.
 Tasa Interna de Retorno TIR (Internal Rate of Return IRR): Se define como la
tasa de interés con la cual el VAN es igual a cero. Se escoge el proyecto que
tenga mayor TIR.
 Payback period (periodo de recuperación): Se define como el número de
periodos que se tarda en recuperar la inversión del proyecto antes de dar
beneficios. Se escoge el proyecto que tenga menor payback.
 Break Even (punto de equilibrio): El punto en el cual los gastos y los beneficios
son equivalentes. El número mínimo de unidades a partir de las cuales ya se
ha cubierto la operación y se genera ganancia. Se escoge el proyecto que
tenga menor break even.
 Benefit Cost Ratio BCR (Ratio Beneficio Coste): Se calcula como el beneficio
del proyecto dividido entre el coste. BCR>1 entonces los beneficios son
superiores a los costes. Se escoge el proyecto que tenga mayor BCR.
Imaginemos un equipo de dirección del proyecto que gestiona eficazmente la

integración. ¿Qué actividades realizaría?
Ejercicio 6. Describa cómo gestionó el alcance el equipo de dirección del

proyecto, en cinco párrafos, usando las siguientes palabras clave:
1. Inicio, patrocinador, desarrollar el acta de constitución del proyecto.
2. Planificación, desarrollar el plan para la dirección del proyecto, reunión de

lanzamiento (kick-off).
3. Ejecución, dirigir y gestionar el trabajo del proyecto, entregables, cambios

aprobados, plan para la dirección del proyecto, documentos del proyecto, datos
de desempeño del trabajo, solicitudes de cambios.
4. Monitorizar y controlar el trabajo del proyecto, desviaciones, solicitudes de

cambios, realizar el control integrado de cambios.
5. Expectativas de los interesados, cerrar el proyecto.
Solución:
1. Durante el inicio del proyecto, el director de proyectos pre-asignado ayudó

al patrocinador a desarrollar el acta de constitución del proyecto, que no
tuvo ningún problema en aprobar y firmar.

2. Una vez completadas las actividades de planificación del proyecto, el equipo

de dirección del proyecto desarrolló una primera versión del Plan para la
Dirección del Proyecto. Este documento fue aprobado por el comité de
dirección del proyecto y se presentó a los principales interesados en la reunión
de lanzamiento (kick-off).
3. Por lo que respecta a la ejecución del proyecto, el equipo de dirección del

proyecto dirigió y gestionó el trabajo del proyecto, supervisando la producción
de los entregables planificados y la implementación de los cambios aprobados,
manteniendo continuamente actualizado el plan para la dirección del proyecto y
el resto de los documentos del proyecto. También registró los datos de
desempeño del trabajo y preparó las solicitudes de cambios.
4. El equipo de dirección del proyecto también se encargó de monitorizar y

controlar el trabajo del proyecto, controlando las desviaciones entre lo
planificado y lo real, preparando nuevas solicitudes de cambios. También se
encargó de realizar el control integrado de cambios: Cada vez que se solicitaba
un cambio que afectaba al plan del proyecto, el equipo de dirección del
proyecto: 1) evaluaba el impacto en todas las áreas; 2) creaba opciones
alternativas; 3) solicitaba la aprobación del comité de control de cambios y 4)
gestionaba las expectativas de los interesados afectados.
5. Una vez los interesados hubieron satisfecho o superado sus expectativas, el

equipo de dirección del proyecto realizó un cierre ordenado del proyecto.

Ejercicio 7. Haga corresponder los términos de la izquierda con las definiciones

a la derecha .
1 Técnicas Analíticas A Diversas técnicas utilizadas para evaluar, analizar o pronosticar resultados potenciales en base a
posibles modificaciones de variables del proyecto o variables ambientales y sus relaciones con otras
variables.
2 Solicitudes de B Un estudio de viabilidad económica documentado utilizado para establecer la validez de los beneficios
Cambio de un componente seleccionado que carece de una definición suficiente y que se usa como base para
Aprobadas la autorización de otras actividades de dirección del proyecto.
3 Caso de Negocio C Un grupo formalmente constituido responsable de revisar, evaluar, aprobar, retrasar o rechazar los
cambios en el proyecto, así como de registrar y comunicar dichas decisiones.
4 Control de D Una actividad intencional para modificar una no conformidad de un producto o de alguno de sus
Cambios componentes.
5 Comité de Control E Una propuesta formal para modificar cualquier documento, entregable o línea base.
de Cambios
6 Registro de F Un proceso por medio del cual se identifican, documentan, aprueban o rechazan las modificaciones
Cambios de documentos, entregables o líneas base asociados con el proyecto.
7 Solicitud de G Una actividad intencional que realinea el desempeño del trabajo del proyecto con el plan para la
Cambio dirección del proyecto.
8 Acción Correctiva H Una lista completa de los cambios realizados durante el proyecto. Normalmente incluye las fechas de
los cambios y los impactos en términos de tiempo, coste y riesgo.
9 Análisis Coste- I Una herramienta de análisis financiero utilizada para determinar los beneficios proporcionados por un
Beneficio proyecto respecto a sus costes.
10 Reparación de J Una solicitud de cambio que se ha procesado a través del proceso de control integrado de cambios y
Defectos que ha sido aprobada.
Solución al Ejercicio 7: 1-A, 2-J, 3-B, 4-F, 5-C, 6-H, 7-E, 8-G, 9-I, 10-D.

a la derecha.
1 Registro de A La serie de fases que representan la evolución de un producto, desde el concepto hasta la entrega, el
Incidentes crecimiento, la madurez y el retiro.
2 Lecciones B Un documento del proyecto utilizado para documentar y monitorear elementos en discusión o
Aprendidas disputa entre los interesados del proyecto.
3 Línea Base para la C La representación física o electrónica de la información sobre el desempeño del trabajo compilada en
Medición del documentos del proyecto, destinada a generar decisiones, acciones o conciencia.
Desempeño
4 Informar el D Una revisión al final de una fase en la que se toma una decisión de continuar a la siguiente fase,
Desempeño continuar con modificaciones o dar por concluido un proyecto o programa.
5 Punto de Revisión E Un documento emitido por el iniciador del proyecto o patrocinador, que autoriza formalmente la
de Fase existencia de un proyecto y confiere al director de proyectos la autoridad para aplicar los recursos de
la organización a las actividades del proyecto.
6 Acción Preventiva F El proceso iterativo de incrementar el nivel de detalle de un plan para la dirección del proyecto a
medida que se cuenta con mayor cantidad de información y con estimaciones más precisas.
7 Ciclo de Vida del G Una actividad intencional que asegura que el desempeño futuro del trabajo del proyecto esté
Producto alineado con el plan para la dirección del proyecto.
8 Elaboración H Un plan aprobado para el trabajo del proyecto con respecto al cual se compara la ejecución del
Progresiva proyecto y se miden las desviaciones con el fin de tomar acciones correctivas o preventivas. Por lo
general, la referencia para la medición del desempeño incluye los parámetros de alcance, cronograma
y coste de un proyecto. Incluye la reserva para contingencias, pero excluye la reserva de gestión.
9 Acta de I La serie de fases que atraviesa un proyecto desde su inicio hasta su cierre.
Constitución del
Proyecto
10 Ciclo de Vida del J El conocimiento adquirido durante un proyecto el cual muestra cómo se abordaron o deberían
Proyecto abordarse en el futuro los eventos del proyecto, a fin de mejorar el desempeño futuro.
Solución al Ejercicio 8: 1-B, 2-J, 3-H, 4-C, 5-D, 6-G, 7-A, 8-F, 9-E, 10-I.


a la derecha.
1 Sistema de A Descripción narrativa de los productos, servicios o resultados a ser entregados por el proyecto.
Información para
la Dirección de
Proyectos
2 Sistema de B Un conjunto específico de procesos, funciones de control relacionadas y herramientas que se
Gestión de consolidan y combinan para registrar y conservar información acerca del proyecto.
Proyectos
3 Equipo de C Un permiso e indicación, generalmente escrito, para comenzar a trabajar específicamente en una
Dirección del actividad del cronograma, paquete de trabajo o cuenta de control. Es un método para autorizar
Proyecto trabajos del proyecto y garantizar que la organización identificada realice el trabajo en el tiempo justo
y con la secuencia correcta.
4 Fase del Proyecto D Las observaciones y mediciones brutas identificadas durante las actividades ejecutadas para llevar a
cabo el trabajo del proyecto.
5 Enunciado del E Los datos de desempeño recopilados de varios procesos de control, analizados en contexto e
Trabajo del integrados en base a las relaciones entre las áreas.
Proyecto
6 Sistema de F La entidad responsable de proporcionar el patrocinador del proyecto y el medio para su
Gestión de financiamiento, así como otros recursos del proyecto.
Registros
7 Sistemas de G Los miembros del equipo del proyecto que participan directamente en las actividades de dirección del
Generación de mismo. En algunos proyectos más pequeños, el equipo de dirección del proyecto puede incluir
Informes prácticamente a todos los miembros del equipo del proyecto.
8 Patrocinador H Una persona o grupo que provee recursos y apoyo para el proyecto, programa o portafolio y que es
responsable de facilitar su éxito.
9 Organización I El acto de seleccionar cuidadosamente los procesos contenidos en la Guía del PMBOK®, así como las
Patrocinadora entradas y salidas relacionadas, a fin de determinar un subconjunto de procesos específicos que se
incluirán dentro de un enfoque global de dirección del proyecto.
10 Adaptar J La suma de los procesos, herramientas, técnicas, metodologías, recursos y procedimientos necesarios
para gestionar un proyecto.
11 Autorización de K Un conjunto de actividades del proyecto relacionadas lógicamente que culmina con la finalización de
Trabajo uno o más entregables.
12 Datos de L Un sistema de información compuesto por herramientas y técnicas utilizadas para recopilar, integrar y
Desempeño del difundir las salidas de los procesos de la dirección de proyectos. Se utiliza para respaldar todos los
Trabajo aspectos del proyecto desde el inicio hasta el cierre, y puede incluir tanto sistemas manuales como
automatizados.
13 Información de M Instalaciones, procesos y procedimientos utilizados para generar o consolidar informes de uno o más
Desempeño del sistemas de gestión de la información y para facilitar la distribución de los informes entre los
Trabajo interesados del proyecto.
Solución al Ejercicio 9: 1-L, 2-J, 3-G, 4-K, 5-A, 6-B, 7-M, 8-H, 9-F, 10-I, 11-C, 12-D,
13-E.

Procesos del área de Gestión de la Integración del Proyecto
Como puede observarse en el mapa de procesos, el área de conocimiento de

Gestión de la Integración del Proyecto tiene procesos en todos los grupos:
En el capítulo 4 de la Guía del PMBOK® se describen seis procesos para la

Gestión de la Integración del Proyecto, que se definen así:
1. Desarrollar el Acta de constitución del proyecto: Desarrollar un documento que

autoriza formalmente la existencia de un proyecto y confiere al director del
proyecto la autoridad para asignar los recursos de la organización ejecutante a
las actividades del proyecto.
2. Desarrollar el Plan para la Dirección del Proyecto: Definir, preparar y coordinar
todos los planes secundarios e incorporarlos en un plan integral para la
dirección del proyecto. Las líneas base y planes secundarios integrados del
proyecto pueden incluirse dentro del plan para la dirección del proyecto.
3. Dirigir y Gestionar el Trabajo del Proyecto: Liderar y llevar a cabo el trabajo
definido en el plan para la dirección del proyecto, así como de implementar los
cambios aprobados, con el fin de alcanzar los objetivos del proyecto.
4. Monitorizar y Controlar el Trabajo del Proyecto: Dar seguimiento, revisar e
informar del avance del proyecto con respecto a los objetivos de desempeño
definidos en el plan para la dirección del proyecto.
5. Realizar el Control Integrado de Cambios: Analizar todas las solicitudes de
cambios; aprobar y gestionar los cambios a los entregables, activos de los
procesos de la organización, documentos del proyecto y plan para la dirección
del proyecto; y comunicar las decisiones correspondientes.

6. Cerrar el Proyecto o Fase: Finalizar todas las actividades en todos los grupos
de procesos de la Dirección de Proyectos para completar formalmente el
proyecto o una fase del mismo.
Entradas, Herramientas y Técnicas, y Salidas
A continuación se enumeran, para cada proceso, las entradas (parte superior),

las herramientas y técnicas (parte central) y las salidas (parte inferior) de los procesos
de Gestión de la Integración del Proyecto:

Los nombres en inglés se transcriben a continuación:
Documentos del área de Gestión de la Integración del Proyecto
A continuación se destacan los documentos relacionados con la Gestión de la

Integración del Proyecto (que como puede apreciarse son todos):
Project Management Plan Project Documents

 Change management plan  Activity attributes  Project schedule
 Communications management plan  Activity cost estimates  Project schedule network diagrams
 Configuration management plan  Activity duration estimates  Project staff assignments
 Cost baseline  Activity list  Project statement of work
 Cost management plan  Activity resource requirements  Quality checklists
 Human resource management plan  Agreements  Quality control measurements
 Process improvement plan  Assumption log  Quality metrics
 Procurement management plan  Basis of estimates  Requirements documentation
 Scope baseline  Change log  Requirements traceability matrix
- Project scope statement  Change requests  Resource breakdown structure
- WBS  Forecasts  Resource calendars
- WBS dictionary - Cost forecast  Risk register
 Quality management plan - Schedule forecast  Schedule data
 Requirements management plan  Issue log  Seller proposals
 Risk management plan  Milestone list  Source selection criteria
 Schedule baseline  Procurement documents  Stakeholder register
 Schedule management plan  Procurement statement of work  Team performance assessments
 Scope management plan  Project calendars  Work performance data
 Stakeholder management plan  Project charter  Work performance information
 Project funding requirements  Work performance reports

Plan de Gestión del Documentos del Proyecto

Proyecto
 Plan de gestión de los cambios  Atributos de las actividades  Cronograma del proyecto
 Plan de gestión de las comunicaciones  Estimación de costes de las actividades  Diagramas de red del cronograma del
 Plan de gestión de la configuración  Estimación de la duración de las proyecto
 Línea base de costes actividades  Asignaciones de personal al proyecto
 Plan de gestión de los costes  Lista de actividades  Enunciado del trabajo del proyecto
 Plan de gestión de los recursos humanos  Requisitos de recursos de las actividades  Listas de verificación de calidad
 Plan de mejoras del proceso  Acuerdos  Mediciones de control de calidad
 Plan de gestión de las adquisiciones  Registro de supuestos  Métricas de calidad
 Línea base del alcance  Base de las estimaciones  Documentación de requisitos
- Enunciado del alcance del proyecto  Registro de cambios  Matriz de trazabilidad de requisitos
- EDT  Solicitudes de cambios  Estructura de desglose de recursos
- Diccionario de la EDT  Pronósticos  Calendarios de recursos
 Plan de gestión de la calidad - Pronósticos de costes  Registro de riesgos
 Plan de gestión de los requisitos - Pronóstico del cronograma  Datos del cronograma
 Plan de gestión de los riesgos  Registro de incidentes  Propuestas de los proveedores
 Línea base del cronograma  Lista de hitos  Criterios de selección de proveedores
 Plan de gestión del cronograma  Documentos de las adquisiciones  Registro de interesados
 Plan de Gestión del Tiempo del Proyecto  Enunciado del trabajo relativo a  Evaluaciones del desempeño del equipo
 Plan de gestión de los interesados adquisiciones  Datos de desempeño del trabajo
 Calendarios del proyecto  Información de desempeño del trabajo
 Acta de constitución del proyecto  Informes de desempeño del trabajo
 Requisitos de financiación del proyecto
1.1. Desarrollar el Acta de Constitución del proyecto
Desarrollar el Acta de Constitución del Proyecto es el proceso de desarrollar un

documento que autoriza formalmente la existencia de un proyecto y confiere al director
del proyecto la autoridad para asignar los recursos de la organización ejecutante a las
actividades del proyecto.

El acta de constitución del proyecto es un documento obligatorio. Ningún

proyecto debería comenzar a consumir recursos de la organización ejecutora si antes
no hay un documento que explique los principales objetivos, requisitos, entregables,
plazos, costes, riesgos, supuestos, etc. También debe justificar las razones por las que
fue aprobado: por qué el proyecto está alineado con la estrategia, crea valor en la
organización, es oportuno, es mejor opción que otros proyectos candidatos, etc. Este
documento es firmado por el patrocinador del proyecto, cuya misión principal es
defender que el proyecto ha de ejecutarse dentro de la organización. Cuando alguien
cuestione por qué se dedican recursos a un proyecto, el director del proyecto
simplemente debería remitirle al acta, y si esto no es suficiente, debería remitirle al
patrocinador.
El acta de constitución del proyecto establece una relación de colaboración

entre la organización ejecutora y la organización solicitante. Si la organización
solicitante encarga un proyecto externo a la organización ejecutora, además existirá un
contrato entre el comprador (organización solicitante o cliente) y el proveedor
(organización ejecutora). Si se trata de un proyecto interno, es decir, la organización
solicitante y la organización ejecutora pertenecen a su vez a la misma organización, el
acta servirá para establecer acuerdos internos y compromisos.
No es obligatorio que en este proceso de inicio participe el director del

proyecto. Muchas veces, se asigna al director del proyecto cuando el proyecto ya ha
sido aprobado, en cuyo caso, lo primero que debe hacer es asegurarse que existe un
acta de constitución y si no es así, conseguir que exista. La mejor práctica es que el
director del proyecto participe en el inicio, cuando el proyecto o la fase aún no se ha
aprobado, de manera que pueda aportar sus conocimientos para asegurar que el acta
contenga toda la información, que han participado los expertos apropiados en el
proceso de decisión, etc. Muchas veces, un proyecto no resulta atractivo simplemente
porque costaría mucho, tardaría mucho, supondría asumir demasiados riesgos, etc.
¿Quién mejor que el director del proyecto para generar unas primeras versiones de los
planes de tiempos, costes, alcance, riesgos, etc.? Si el proyecto o fase se aprueba, el
director del proyecto habrá invertido un esfuerzo muy rentable identificando
interesados e iniciando los planes. Si el resultado es que no se aprueba, seguramente
el proceso de decisión facilitado por el director del proyecto ha sido más eficaz para la
organización ejecutora.
Los proyectos son iniciados por una entidad externa a los mismos, como un
patrocinador, un programa o una persona de la oficina de dirección de proyectos
(PMO), o el presidente de un órgano de gobierno del portafolio o su representante
autorizado. El iniciador del proyecto o patrocinador debe encontrarse en el nivel
adecuado para obtener la financiación del proyecto y comprometer recursos para el
mismo. Los proyectos se inician como consecuencia de necesidades internas de la
empresa o de influencias externas.

1.1.1. ENTRADAS
 Enunciado del trabajo del proyecto: El Project Statement Of Work (SOW) es

una descripción narrativa de los productos o servicios que debe entregar el
proyecto. Tendrá en cuenta, al menos:
 La necesidad del negocio. Las necesidades del negocio de una
organización pueden deberse a una demanda del mercado, una
necesidad organizativa, una petición de un cliente, un avance
tecnológico, un requisito legal o regulación gubernamental, reducir el
impacto ecológico o satisfacer una necesidad social.
 La descripción del alcance del producto. Documenta las características
del producto que el proyecto se encargará de crear. La descripción
también debe documentar la relación entre los productos o servicios
que se están creando y la necesidad comercial que el proyecto
atenderá.
 El plan estratégico. Todos los proyectos deben sustentar las metas
estratégicas de la organización. El plan estratégico de la organización
ejecutante debe considerarse como un factor de decisión y de
priorización al seleccionar el proyecto.
 Caso de negocio: El caso de negocio o documento similar proporciona la
información necesaria desde una perspectiva comercial para determinar si el
proyecto vale o no la inversión requerida. En el caso de proyectos externos, la
organización solicitante o el cliente pueden elaborar el caso de negocio.
Normalmente, para justificar el proyecto, el caso de negocio incluye la
necesidad del negocio y el análisis coste-beneficio. La necesidad del negocio
puede deberse a una demanda de mercado, una necesidad organizativa, una
solicitud de un cliente, avances tecnológico, un requisito legal, impacto
ecológico, necesidades sociales, etc. En el caso de proyectos de fases
múltiples, el caso de negocio debería ser revisado periódicamente para
asegurarse de que el proyecto sigue orientado hacia el logro de los beneficios
para el negocio. En las primeras etapas del ciclo de vida del proyecto, la
revisión periódica del caso de negocio por parte de la organización
patrocinadora también ayuda a confirmar que el proyecto sigue siendo
necesario.
 Acuerdos: Los acuerdos se establecen para definir las intenciones iniciales de
un proyecto. Los acuerdos pueden tomar la forma de contratos, memorandos
de entendimiento (MOUs), acuerdos de nivel de servicio (SLAs), cartas de
acuerdo, declaraciones de intenciones, acuerdos verbales, correos electrónicos
u otros acuerdos escritos.

 Factores Ambientales de la Empresa: Algunos factores que pueden influir en

este proceso:
 Estándares gubernamentales, estándares de la industria o reglamentos
(p.ej., códigos de conducta, estándares de calidad o estándares de
protección del trabajador).
 Cultura y estructura de la organización.
 Condiciones del mercado.
 Activos de los Procesos de la Organización: Algunos activos que pueden influir
en este proceso:
 Procesos estándar de la organización, políticas y definiciones de
procesos.
 Plantillas (p.ej., plantilla del acta de constitución del proyecto).
 Información histórica y base de conocimientos de lecciones aprendidas
(p.ej., proyectos, registros y documentos, toda la información y
documentación de cierre del proyecto, información tanto sobre los
resultados de las decisiones de selección de proyectos anteriores y
sobre el desempeño de proyectos anteriores, como sobre las
actividades de gestión de riesgos).
1.1.2. HERRAMIENTAS Y TÉCNICAS
 Juicio de expertos. El juicio de expertos se aplica a todos los detalles técnicos y

de gestión a lo largo de este proceso. Esta experiencia puede ser
proporcionada por cualquier grupo o individuo con conocimientos o formación
especializados, y se encuentra disponible a través de diferentes fuentes, entre
las que se incluyen:
 Otras unidades dentro de la organización.
 Consultores.
 Interesados, incluidos clientes y patrocinadores.
 Asociaciones profesionales y técnicas.
 Grupos industriales.
 Expertos en la materia (SME).
 Oficina de dirección de proyectos (PMO).
 Técnicas de facilitación: Las técnicas de facilitación tienen una amplia
aplicación en el ámbito de los procesos de la dirección de proyectos y guían el
desarrollo del acta de constitución del proyecto. Tormentas de ideas, resolución
de conflictos, solución de problemas y gestión de reuniones son ejemplos de
técnicas clave que utilizan los facilitadores para ayudar a equipos e individuos
a llevar a cabo las actividades del proyecto.

1.1.3. SALIDAS
 Acta de constitución del proyecto: El acta de constitución del proyecto es un

documento emitido por el iniciador del proyecto o patrocinador, que autoriza
formalmente la existencia de un proyecto y confiere al director del proyecto la
autoridad para asignar los recursos de la organización a las actividades del
proyecto. Documenta las necesidades de negocio, los supuestos, las
restricciones, el conocimiento de las necesidades y requisitos de alto nivel del
cliente y el nuevo producto, servicio o resultado que el proyecto debe
proporcionar, como por ejemplo:
 El propósito o la justificación del proyecto.
 Los objetivos medibles del proyecto y los criterios de éxito asociados.
 Los requisitos de alto nivel.
 Los supuestos y las restricciones.
 La descripción de alto nivel del proyecto y sus límites.
 Los riesgos de alto nivel.
 El resumen del cronograma de hitos.
 El resumen del presupuesto.
 La relación de interesados.
 Los requisitos de aprobación del proyecto (es decir, en qué consiste el
éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la
aprobación del proyecto).
 El director del proyecto asignado, su responsabilidad y su nivel de
autoridad.
 El nombre y el nivel de autoridad del patrocinador o de quienes
autorizan el acta de constitución del proyecto.
1.2. Identificar a los Interesados
Identificar a los Interesados es el proceso de identificar a las personas, grupos

u organizaciones que podrían ejercer o recibir el impacto de una decisión, actividad o
resultado del proyecto. Analizar y documentar información relevante relativa a sus
intereses, participación, interdependencias, influencia y posible impacto en el éxito del
proyecto. El beneficio clave de este proceso es que permite al director del proyecto
identificar el enfoque adecuado para cada interesado o grupo de interesados.

Para el éxito del proyecto, resulta fundamental identificar a los interesados

desde el comienzo del mismo y analizar sus niveles de interés, expectativas,
importancia e influencia. Se puede elaborar entonces una estrategia para abordar a
cada uno de ellos y determinar el nivel y el momento de su participación, a fin de
maximizar las influencias positivas y mitigar los impactos negativos potenciales.
La evaluación y la estrategia correspondiente deben revisarse de forma

periódica durante la ejecución del proyecto para ser ajustadas frente a eventuales
cambios.
La mayoría de los proyectos tendrán gran cantidad de interesados. Dado que el

tiempo con el que cuenta el director del proyecto es limitado y debe usarse con la
mayor eficiencia posible, estos interesados deberían ser clasificados según su interés,
influencia y participación en el proyecto. Esto permite que el director del proyecto se
concentre en las relaciones necesarias para asegurar el éxito del proyecto.
1.2.1. ENTRADAS
 Acta de constitución del proyecto: Puede suministrar información sobre los

interesados internos y externos, tales como el patrocinador y otros miembros
de la organización patrocinadora, el cliente y otros miembros de la organización
solicitante, los miembros del equipo o recursos clave ya identificados, grupos y
departamentos que participan en el proyecto, así como otras personas u
organizaciones afectadas por el mismo, etc.
 Documentos de la adquisición: Si el proyecto es el resultado de una actividad
de adquisición o si se basa en un tipo de acuerdo, las partes en dicho acuerdo
son interesados clave del proyecto.

 Factores Ambientales de la Empresa: Algunos factores ambientales que

pueden influir en este proceso:
 La cultura y la estructura de la organización.
 Los estándares gubernamentales o del sector de actividad (p.ej.,
regulaciones, estándares de productos).
 Las tendencias globales, regionales o locales, y las prácticas o hábitos.
en este proceso:
 Plantillas de registro de interesados.
 Lecciones aprendidas de proyectos o fases anteriores.
 Registros de interesados de proyectos anteriores.
 Análisis de interesados: Consiste en recopilar y analizar de manera sistemática

información cuantitativa y cualitativa, a fin de determinar qué intereses
particulares deben tenerse en cuenta a lo largo del proyecto. Permite saber qué
tipo de interés tienen los interesados en el proyecto, sus requisitos principales,
sus interrelaciones con otros interesados, el grado de influencia que pueden
ejercer sobre el proyecto, etc.
A la hora de identificar y analizar a los potenciales interesados en el proyecto,

conviene plantear las siguientes preguntas:
 ¿Quién recibe el resultado del proyecto?

 ¿Quién suministra la información de entrada?
 ¿Quién tiene capacidad de supervisión?
 ¿Quién tiene otras responsabilidades relacionadas?
 ¿Quién cosecha los beneficios?
 ¿Quién sufre las penalizaciones?

Existen múltiples modelos de clasificación utilizados para el análisis de

interesados, tales como:
 Matriz de poder/interés: Poder (autoridad) x Interés (nivel de

preocupación).
 Matriz de poder/influencia: Poder (autoridad) x Influencia (participación
activa).
 Matriz de influencia/impacto: Influencia (participación activa) x Impacto
(capacidad de efectuar cambios a la planificación o ejecución del
proyecto).
 Modelo de prominencia (salience model): Poder (capacidad de imponer
su voluntad) x Urgencia (necesidad de atención inmediata) x
Legitimidad (su participación es adecuada).
 Juicio de expertos: Para asegurar la identificación y el listado exhaustivo de los

interesados, se debería procurar el juicio y la experiencia de grupos o personas
con capacitación especializada o pericia en la materia. El juicio de expertos
puede obtenerse mediante consultas individuales (reuniones personalizadas,
entrevistas, etc.) o mediante un formato de panel (grupos focales, encuestas,
etc.).
 Reuniones: Las reuniones de análisis del perfil de los interesados son
reuniones de proyecto diseñadas para desarrollar el conocimiento sobre los
principales interesados del proyecto, y se pueden utilizar para intercambiar y
analizar información sobre roles, intereses, conocimientos y la postura general
de cada uno de los interesados respecto al proyecto.
1.2.3. SALIDAS
 Registro de interesados: Contiene todos los detalles relacionados con los

interesados identificados, entre ellos:
 Información de identificación: Nombre, puesto en la organización,

ubicación, rol en el proyecto, información de contacto, etc.
 Información de evaluación: Principales requisitos, principales
expectativas, influencia potencial en el proyecto, fase en el ciclo de vida
donde el interés es mayor, etc.
 Información de clasificación de interesados: interno/externo,
partidario/neutral/opositor, etc.

El registro de interesados se debe consultar y actualizar de manera regular, ya

que los interesados podrían cambiar, o se podrían identificar nuevos, a lo largo
del ciclo de vida del proyecto.
A continuación se ofrece un extracto del registro de interesados utilizado en el

caso práctico desarrollado en el anexo I:
Clasifica Fase de Poder/

Nombre Rol Requisitos Expectativas Posible influencia ción +interés Interés*
Anton Zandhuis Autor Consistencia con Traducción de Cambios en el a favor Traducci 5/5
la Guía del alta calidad original. Gestión. ón
PMBOK® v5.
Bart Verbrugge Editor Lector público en Libro publicado Peticiones de a favor Edición 5/5
general. en febrero 2014 maquetación y
marketing.
Diana Hochraich Revisor Lector público en Alta calidad Cambios de neutral Edición 2/3
Editorial general. inicial de la redacción español.
traducción
Revisores PMI Revisores Consistencia con Difusión PMI Cambios de a favor Traducci 2/3
Buenos Aires externos PMI la Guía del redacción español. ón
Buenos Aires PMBOK® v5.
Lectores Latam.
(*) De 1 (más bajo) a 5 (más alto)
1.3. Planificar la Gestión de los Interesados
Planificar la Gestión de los Interesados es el proceso de desarrollar estrategias

de gestión adecuadas para lograr la participación eficaz de los interesados a lo largo
del ciclo de vida del proyecto, con base en el análisis de sus necesidades, intereses y
el posible impacto en el éxito del proyecto. El beneficio clave de este proceso es que
proporciona un plan claro y factible para interactuar con los interesados del proyecto a
fin de apoyar los intereses del mismo.

La gestión de los interesados trata de la creación y el mantenimiento de

relaciones entre el equipo y los interesados del proyecto, con objeto de satisfacer sus
necesidades y requisitos respectivos dentro de los límites del proyecto. El proyecto
terminará cuando los interesados alcanzan o superan sus expectativas, pero esto no
se improvisa. Si el día del cierre hay interesados insatisfechos, el proyecto tendrá un
cierre muy complicado, o no podrá cerrarse. Hay que planificar cómo vamos a
involucrarles y cómo asegurar que permanezcan involucrados. Para aquellos que
necesitamos que se involucren más en el proyecto, habrá que trazar una estrategia de
gestión, y revisar continuamente que la gestión de los interesados sigue siendo
efectiva.
1.3.1. ENTRADAS
 Plan para la dirección del proyecto: Contiene el plan de gestión del alcance
(qué trabajos hay que hacer), el plan de gestión de recursos humanos (cómo
se cumplirán los requisitos de recursos humanos y se administrará el personal
del equipo), el plan de gestión de cambios y el plan de gestión de las
comunicaciones.
 Registro de interesados: Proporciona la información necesaria para planificar
formas adecuadas de involucrar a los interesados del proyecto.
 Factores Ambientales de la Empresa: Algunos factores ambientales que
pueden influir en este proceso son: la cultura, la estructura y el clima político de
la organización.
en este proceso son: la base de datos de lecciones aprendidas y la información
histórica.

 Juicio de expertos: El director del proyecto, sobre la base de los objetivos del
proyecto, debe recurrir al juicio de expertos para decidir sobre el nivel de
participación requerido de cada uno de los interesados en cada etapa del
proyecto.
 Reuniones: Se deben mantener reuniones con expertos y el equipo del
proyecto para definir los niveles de participación requeridos de cada uno de los
interesados.
 Técnicas analíticas: El nivel de participación de los interesados se puede
clasificar de la siguiente manera:
 Desconocedor (unaware): Desconocedor del proyecto y de sus
impactos potenciales.
 Reticente (resistant): Conocedor del proyecto y de sus impactos
potenciales, y reticente al cambio.
 Neutral: Conocedor del proyecto, aunque ni lo apoya ni es reticente.
 Partidario (supportive): Conocedor del proyecto y de sus impactos
potenciales, y apoya el cambio.
 Líder (leading): Conocedor del proyecto y de sus impactos potenciales,
y activamente involucrado en asegurar el éxito del mismo.
Una matriz de evaluación de la participación de los interesados permite

identificar las brechas entre los niveles de participación actuales y deseados. El
equipo de dirección del proyecto puede identificar las acciones y
comunicaciones necesarias para cerrar estas brechas.
1.3.3. SALIDAS
 Plan de gestión de los interesados: Además del registro de interesados,

incluye:
 El nivel de participación deseado y actual de los interesados clave.

El alcance e impacto del cambio para los interesados.

Las interrelaciones y posible superposición entre interesados que se
hayan identificado.
 Los requisitos de comunicación de los interesados para la fase actual
del proyecto.
 La información a distribuir entre los interesados, incluidos el lenguaje,
formato, contenido y nivel de detalle.
 El motivo para la distribución de dicha información y el impacto
esperado en la participación de los interesados.
 El plazo y la frecuencia para la distribución de la información necesaria
a los interesados.
 El método para actualizar y refinar el plan de administración de los
interesados a medida que avanza y se desarrolla el proyecto.
 Actualizaciones a los documentos del proyecto: Entre los documentos
susceptibles de actualización en este proceso se cuentan: El cronograma del
proyecto y el registro de interesados.
2. CREACIÓN DE LA EDT Y EL DICCIONARIO DE LA

EDT
La Gestión del Alcance del Proyecto incluye los procesos necesarios para
garantizar que el proyecto incluya todo el trabajo requerido (y únicamente el trabajo
requerido) para completar el proyecto con éxito. Gestionar el alcance del proyecto
consiste principalmente en definir y controlar qué se incluye y qué no se incluye en el
proyecto.
En el contexto del proyecto, el término alcance puede referirse a:
 Alcance del producto: Las características y funciones que definen un producto,

servicio o resultado.
 Alcance del proyecto: El trabajo realizado para entregar un producto, servicio o
resultado con las funciones y características especificadas.
Desde los Requisitos del Proyecto a la Línea Base del Alcance
Determinar los requisitos supone la mayor carga de gestión inicial en cualquier

proyecto. El director del proyecto debe comenzar con el fin en la mente. Esa imagen
final del proyecto, el momento del cierre, se visualiza con los interesados alcanzando o
superando sus expectativas. En la presentación fin de proyecto, se comunica
explícitamente que todo está terminado, se describen los logros y objetivos cumplidos,
cómo será la siguiente fase del proyecto o la operación del producto, cómo se dará
soporte, en qué consistirán las actividades durante el periodo de garantía, etc.

Esta “escenificación” sirve para trasladar un mensaje claro a los interesados:

todo está terminado y ya no tienen derecho a solicitar más cambios.
Con el fin de gestionar el proyecto para que su cierre sea efectivo, desde el
comienzo de la gestión hay que saber qué quieren los interesados, o lo que es lo
mismo: sus requisitos. Especialmente importantes son los requisitos de quienes deben
aceptar el producto del proyecto, es decir, aquellos que van a ejercer el papel de
clientes del proyecto, u organización solicitante Los requisitos tienen una gestión
complicada porque suelen cambiar muy a menudo. Muchas veces los clientes no
saben lo que quieren (siempre saben lo que no quieren: hasta que no tienen una
entrega no suelen pronunciarse). Cada vez es menos frecuente que los clientes nos
aprueben formalmente una línea base de requisitos, pero no por ello hay que desistir
en este objetivo de gestión. ¿Qué es lo peor que puede ocurrir en un proyecto? Que
los requisitos cambien todos los días (esto se denomina corrupción del alcance o
scope creep). ¿Cómo podemos mitigar este riesgo? Escribiendo una lista de
requisitos, documentada de tal manera que sirva para especificar el producto y para
consensuar la definición de trabajo terminado (definition of done) o lo que es lo mismo:
la condición para cerrar el proyecto. Si todo está terminado en las condiciones
pactadas, entonces se puede cerrar el proyecto.
Gestionar el alcance en proyectos es diferente que gestionar el alcance en

operaciones. Pensemos en el caso práctico desarrollado en el anexo, el proyecto de
traducir un libro. Un traductor que se dedique habitualmente a traducir textos, o a
corregirlos, no está ejecutando proyectos, sino que su actividad es repetitiva. A pesar
de que no son proyectos, estos trabajos de traducción tienen requisitos de producto de
tipo funcional (idioma destino, textos a traducir, gráficos a traducir, etc.), y requisitos de
producto de tipo no funcional (adaptación al estilo de los potenciales lectores, estilos
de redacción, formatos de texto, etc.). También tienen requisitos de gestión (plazos de
entrega, proceso de revisiones, material de marketing, etc.).
Cuando la traducción es un proyecto como en nuestro caso práctico, sigue

siendo muy importante cumplir los objetivos de producto, pero quizá sea más
importante “envolver” el resultado a obtener dentro de un esfuerzo organizado, dirigido
a cumplir los objetivos del proyecto: fecha de entrega, voluntariado del PMI, consenso
de profesionales, etc. Si la editorial hubiera encargado que cada voluntario tradujese
ciertos capítulos, no sería un proyecto. Sin embargo, la editorial encargó una
traducción completa y dio libertad de gestión. Los requisitos de producto de la
traducción siguen estando allí, pero hay que “envolver” esos objetivos en una entidad
de gestión mayor, llamada proyecto.
Como se puede observar en la figura, el alcance de un proyecto incluye

elementos del producto del proyecto (producto, servicio, o resultado final) y de
proyecto, o proceso (cómo hay que trabajar para conseguir que el producto y el
proyecto cumplan los objetivos).

En los procesos de la Guía del PMBOK® veremos que la planificación del

alcance comienza recopilando los requisitos. Muchas veces esta documentación de
requisitos se denomina “línea base de requisitos”, con el objetivo de gestionar los
cambios, las entregas y las aceptaciones de requisitos comparando con una referencia
escrita.
Para gestionar el proyecto, sin embargo, no es suficiente con saber qué

funcionalidades hay que entregar, sino que hay que diseñar los trabajos para cumplir
los objetivos de tiempo, coste, calidad, etc. Es decir, se trata de “envolver” el trabajo
técnico con los trabajos, o esfuerzos necesarios, dirigidos a cumplir los objetivos. Esto
se llama línea base del alcance. La línea base del alcance del proyecto consta de tres
elementos: una narración cuanto más breve mejor (enunciado del alcance); una
Estructura de Desglose de Trabajos (EDT) representada preferiblemente de forma
gráfica, y una explicación detallada de los paquetes de trabajo (diccionario de la EDT).
Primero se comienza por los requisitos, para elaborar después la línea base del
alcance, pero son procesos muy “re-entrantes” porque los requisitos cambian, y es
básico mantener la línea base del alcance actualizada para tener una planificación
realista.
Así pues, podemos decir que en un proyecto hay dos alcances: el alcance de
producto y el alcance de proyecto. Si bien el director del proyecto debe gestionar el
alcance de forma integrada, el alcance de producto se valida contra la línea base de
requisitos y el alcance del proyecto se valida contra la línea base del alcance.
Una buena planificación del alcance servirá para orientar al equipo de dirección
del proyecto en la toma de decisiones a la hora de decidir añadir o quitar trabajos, y al
controlar qué está incluido y qué no, tanto en el proyecto como en el producto del
proyecto.

Corrupción del Alcance (Scope Creep)
Una adecuada gestión del alcance del proyecto aporta innumerables

beneficios. Por el contrario, la peor forma de gestionar el alcance es cuando se
permite que ocurra la corrupción del alcance, o scope creep. La Guía del PMBOK®
define scope creep como la expansión no controlada del alcance del producto o
proyecto sin ajustes de tiempo, coste y recursos. La corrupción del alcance puede
originarse por muchas causas, entre las más frecuentes están las siguientes:
 Definición deficiente de los requisitos iniciales.

 Involucración insuficiente de los usuarios en las etapas iniciales del proyecto,
especialmente en la recopilación de requisitos.
 Falta de una línea base del alcance.
 Control de cambios deficiente.
 Duración muy larga del proyecto, durante la cual cambian demasiado los
requisitos.
 Deficiente gestión de las expectativas de los usuarios.
Imaginemos un equipo de dirección del proyecto que gestiona eficazmente el

alcance. ¿Qué actividades realizaría?
Ejercicio 1. Describa cómo gestionó el alcance el equipo de dirección del

proyecto, en nueve párrafos, usando las siguientes palabras clave:
1. Taller de requisitos, prototipos, documento de requisitos, matriz de trazabilidad

de requisitos.
2. Generación de alternativas, entregables, enunciado del alcance del proyecto.
3. Miembros del equipo, paquetes de trabajo, EDT, cuentas de control.
4. Plantilla EDT, diccionario de la EDT, línea base del alcance.
5. Miembros del equipo, códigos de cuentas.
6. Scope creep.
7. Control del alcance, grado de avance, desviaciones sobre la línea base,
sistema de control de cambios.
8. Sistema de gestión de la configuración, validación del alcance, aceptación del
cliente.
9. Entregables aceptados.
Solución:
1. La sesión dedicada al taller de requisitos con los interesados resultó muy

productiva porque se eliminaron muchas ambigüedades, algunos de los
requisitos identificados se aplazaron para siguientes versiones y lo más
importante: sintieron que sus requisitos se habían entendido y declararon su
apoyo al proyecto. Los dos prototipos que se presentaron posteriormente a los
interesados les hicieron comprender que el nuevo producto resolvería gran
parte de sus problemas actuales. Se elaboró el documento de requisitos y una
matriz de trazabilidad de requisitos.

2. El equipo de gestión generó y decidió entre distintas alternativas para cumplir

los requisitos, y comenzaron a tener claros los entregables. Además de
documentar los entregables, desarrollaron una descripción de qué incluía el
proyecto, qué estaba excluido y por qué, restricciones, supuestos, criterios de
aceptación, etc. Toda esta información sirvió para elaborar el enunciado del
alcance del proyecto, que fue aceptado por el comité de seguimiento.
3. Para especificar apropiadamente los trabajos que debían ejecutar los
miembros del equipo, se descompuso el alcance en partes gestionables
llamadas paquetes de trabajo y se representó esta descomposición jerárquica
en forma de árbol invertido denominado EDT (Estructura de Desglose de
Trabajos), señalando los nodos cuentas de control, que serían objeto de control
sobre el grado de avance, costes y tiempos.
4. Como este proyecto era muy parecido a otro ejecutado el año pasado en esa
organización ejecutora, se decidió reutilizar aquella EDT como plantilla.
También se reutilizó ampliamente el diccionario de la EDT. Con el enunciado
del alcance, la EDT y el diccionario de la EDT, se preparó el documento línea
base del alcance, que serviría al equipo de gestión para controlar que se hacen
los trabajos previstos y no otros, y controlar las desviaciones.
5. Los miembros del equipo comprendieron los paquetes de trabajo que les
habían sido asignados y comenzaron a prepararse para el trabajo. El personal
del departamento financiero preparó los códigos de cuentas a los que deberían
imputar las horas de trabajo incurridas.
6. Consultando el dossier del proyecto anterior, en el registro de gestión de
cambios, el director de proyectos pudo constatar que hubo “corrupción del
alcance” (scope creep), ya que se añadieron muchas funcionalidades por el
mero capricho de ciertos interesados, sin la aprobación formal del cliente. El
director del proyecto incluyó este problema en su lista inicial de riesgos, y
decidió mitigarlo aplicando estrictamente los procedimientos de control
integrado de cambios de la organización ejecutora.
7. Durante la ejecución, el control del alcance se trataba en cada reunión de
seguimiento: el director del proyecto representaba el grado de avance sobre
cada paquete de trabajo, y se analizaban las desviaciones sobre la línea base.
El cliente solicitó cambios de alto impacto en dos entregables, lo cual supuso
renegociar el presupuesto del proyecto, que se contrató en su día a precio
cerrado. Todos los cambios fueron debidamente documentados y aprobados a
través del sistema integrado de control de cambios.
8. Por otra parte, cada vez que se producía una entrega, cuyos elementos se
etiquetaban como “entregados” siguiendo el sistema de gestión de la
configuración, el director del proyecto aseguraba la validación del alcance
haciendo que el cliente comunicara su aceptación por escrito.
9. En la última reunión de seguimiento, el director del proyecto ratificó que todos
los entregables estaban completos y aceptados, por lo que decidió convocar a
los principales interesados para la reunión de cierre.


a la derecha.
1 Sistema de Control A Documento que provee, para uso común y repetitivo, las reglas, pautas o características que deberían
de Cambios cumplir las actividades (o sus resultados), a fin de obtener un óptimo grado de orden en un contexto
dado.
2 Sistema de Gestión B Acción tomada para hacer que un componente defectuoso o no conforme cumpla con las
de la Configuración disposiciones de los requisitos o especificaciones.
3 Entregable C Un subsistema del sistema de dirección de proyectos general. Es un conjunto de procedimientos
formalmente documentados que se utilizan para implementar la dirección y supervisión técnica y
administrativa para: identificar y documentar las características funcionales y físicas de un producto,
resultado, servicio o componente; controlar cualquier cambio a dichas características; registrar e
informar cada cambio y su estado de implementación; y brindar apoyo a la auditoría de productos,
resultados o componentes para verificar su conformidad con los requisitos. Incluye la documentación,
los sistemas de rastreo y la definición de los niveles de aprobación necesarios para autorizar y
controlar los cambios.
4 Producto D Una condición o capacidad que debe estar presente en un producto, servicio o resultado para
satisfacer un contrato u otra especificación formalmente impuesta.
5 Alcance del E Un artículo producido, que es cuantificable y que puede ser un elemento terminado o un
Producto componente.
6 Alcance del F Una salida de la ejecución de procesos y actividades de dirección de proyectos. Los resultados
Proyecto incluyen consecuencias (p.ej., sistemas integrados, procesos revisados, organización reestructurada,
pruebas, personal capacitado, etc.) y documentos (p.ej., políticas, planes, estudios, procedimientos,
especificaciones, informes, etc.).
7 Requisito G El trabajo realizado para entregar un producto, servicio o resultado con las funciones y características
especificadas.
8 Resultado H El proceso realizado para asegurar que un producto, servicio o sistema cumple con las necesidades del
cliente y de otros interesados identificados. A menudo implica corroborar la aceptación y
conveniencia con clientes externos.
9 Retrabajo I Los rasgos y funciones que caracterizan a un producto, servicio o resultado.
10 Alcance J La versión aprobada de un enunciado del alcance, estructura de desglose del trabajo (EDT), y su
diccionario de la EDT asociado, que sólo puede cambiarse a través de procedimientos formales de
control de cambios y que se utiliza como base de comparación.
11 Línea Base del K Cualquier producto, resultado o capacidad de prestar un servicio único y verificable que debe
Alcance producirse para terminar un proceso, una fase o un proyecto.
12 Especificaciones L Un documento que expresa de manera completa, precisa y verificable, los requisitos, el diseño, el
comportamiento y otras características de un sistema, componente, producto, resultado o servicio así
como los procedimientos para determinar si se ha cumplido con estas disposiciones.
13 Estándar M La suma de productos, servicios y resultados a ser proporcionados como un proyecto.
14 Validación N Un conjunto de procedimientos que describe la forma en que se gestionan y controlan las
modificaciones de los entregables y la documentación del proyecto.
15 Verificación O Proceso que consiste en evaluar si un producto, servicio o sistema cumple o no con determinada
regulación, requisito, especificación o condición impuesta. A menudo se trata de un proceso interno.
Solución al Ejercicio 2: 1-N, 2-C, 3-K, 4-E, 5-I, 6-G, 7-D, 8-F, 9-B, 10-M, 11-J, 12-L,
13-A, 14-H, 15-O.


a la derecha.
1 Diagrama de Afinidad A Una técnica de extracción de Información que contempla sesiones enfocadas en las cuales se
reúnen los interesados interdisciplinarios clave para definir los requisitos del producto.
2 Pila B Una representación visual del alcance del producto que muestra un sistema empresarial
(proceso, equipos, sistema informático, etc.) y cómo las personas y otros sistemas (actores)
interactúan con él.
3 Estudios Comparativos C Conjuntos de preguntas escritas diseñadas para acumular información rápidamente, proveniente
de un amplio número de encuestados.
4 Tormenta de ideas D Una técnica de creatividad grupal que permite clasificar en grupos un gran número de ideas para
su revisión y análisis.
5 Diagramas de Contexto E Los estudios comparativos cotejan las prácticas reales o planificadas, tales como procesos y
operaciones, con las prácticas de organizaciones comparables a fin de identificar las mejores
prácticas, generar ideas para mejorar y proporcionar una base para medir el desempeño.
6 Técnica Delphi F Una representación gráfica de situaciones que muestran las influencias causales, la cronología de
eventos y otras relaciones entre las variables y los resultados.
7 Dictadura G Una técnica grupal de toma de decisiones en la que un individuo toma la decisión por el grupo.
8 Talleres Facilitados H Una técnica que proporciona un modo directo de visualizar a los individuos en su entorno
desempeñando sus trabajos o tareas y llevando a cabo procesos.
9 Grupos Focales I Una técnica que mejora la tormenta de ideas, mediante un proceso de votación que se usa para
jerarquizar las ideas más útiles, para realizar una tormenta de ideas adicional, o para asignarles
prioridades.
10 Mapa J Un método para obtener una retroalimentación temprana respecto de los requisitos,
Conceptual/Mental proporcionando un modelo operativo del producto esperado antes de construirlo realmente.
11 Diagrama de K Una técnica general de recolección de datos y creatividad que puede usarse para identificar los
Influencias riesgos, ideas o soluciones a incidentes mediante la participación de un grupo de miembros del
equipo o expertos en el tema.
12 Técnicas de Grupo L Una técnica para recabar información que se utiliza como método para lograr el consenso de
Nominal expertos en un tema. Los expertos en el tema participan en esta técnica en forma anónima. Un
facilitador utiliza un cuestionario para solicitar ideas acerca de los puntos importantes del
proyecto relacionados con dicho tema. Las respuestas son resumidas y luego son enviadas
nuevamente a los expertos para comentarios adicionales. En pocas rondas, mediante este
proceso se puede lograr el consenso. Esta técnica ayuda a reducir sesgos en los datos y evita que
cualquier persona ejerza influencias impropias en el resultado.
13 Observaciones M Un listado de requisitos y entregables del producto a ser completados, escritos como historias y
priorizados por el negocio para gestionar y organizar el trabajo del proyecto.
14 Prototipos N Una técnica de obtención que reúne a participantes precalificados y expertos en la materia para conocer sobre
sus expectativas y actitudes con respecto a un producto, servicio o resultado propuesto.
15 Cuestionarios y O Técnica utilizada para consolidar las ideas que surgen durante sesiones individuales de tormenta de ideas en un
Encuestas esquema único para reflejar los puntos en común y las diferencias de entendimiento y así generar nuevas
ideas.
Solución al Ejercicio 3: 1-D, 2-M, 3-E, 4-K, 5-B, 6-L, 7-G, 8-A, 9-N, 10-O, 11-F, 12-I,
13-H, 14-J, 15-C.


a la derecha.
1 Generación de A Una técnica utilizada para desarrollar tantas opciones potenciales como sea posible a fin de
Alternativas identificar diferentes enfoques para ejecutar y llevar a cabo el trabajo del proyecto.
2 Valor del Negocio B Técnica de planificación utilizada para proveer productos, servicios y resultados que reflejen
fielmente los requisitos del cliente traduciéndolos en requisitos técnicos apropiados para cada fase
del desarrollo de producto del proyecto.
3 Hojas de C El trabajo definido en el nivel más bajo de la estructura de desglose del trabajo para el cual se puede
Verificación estimar y gestionar el coste y la duración.
4 Código de Cuentas D Un sistema de numeración que se utiliza para identificar de forma única cada uno de los
componentes de la estructura de desglose del trabajo (EDT).
5 Cuenta de Control E Una representación jerárquica de la organización del proyecto que ilustra la relación entre las
actividades del proyecto y las unidades de la organización que llevarán a cabo esas actividades.
6 Estructura de F La expansión no controlada del alcance del producto o proyecto sin ajustes de tiempo, coste y
Desglose de la recursos.
Organización (OBS)
7 Porcentaje G Una estimación expresada como un porcentaje de la cantidad de trabajo que se ha terminado de una
Completado actividad o un componente de la estructura de desglose del trabajo.
8 Paquete de H Una descripción del modo en que los requisitos individuales cumplen con las necesidades de negocio
Planificación del proyecto.
9 Documentación de I Una medida de la tasa de productividad de un equipo en la cual se producen, validan y aceptan los
Requisitos entregables dentro de un intervalo de tiempo predefinido. Enfoque de planificación de la capacidad
usado frecuentemente para pronosticar el trabajo futuro en el proyecto.
10 Matriz de J Una cuadrícula que vincula los requisitos del producto desde su origen hasta los entregables que los
Trazabilidad de satisfacen.
Requisitos
11 Corrupción o K Un concepto que es único para cada organización e incluye elementos tangibles e intangibles. A
deslizamiento del través del uso eficaz de las disciplinas de dirección de proyectos, programas y Dirección de Portafolio,
Alcance las organizaciones tendrán la capacidad de emplear procesos confiables y establecidos para cumplir
con los objetivos empresariales y obtener mayor valor de negocio a partir de sus inversiones.
12 Enunciado del L Un punto de control administrativo donde se integran el alcance, el presupuesto, el coste real y el
Trabajo (SOW) cronograma, y se comparan con el valor ganado para la medición del desempeño.
13 Velocidad M Una hoja de anotaciones que puede utilizarse como lista de control cuando se recopilan datos.
14 Voz del Cliente N Un componente de la estructura de desglose del trabajo bajo la cuenta de control con contenido de
trabajo conocido pero sin actividades detalladas en el cronograma.
15 Paquete de O Descripción narrativa de los productos, servicios o resultados a ser entregados por el proyecto.
Trabajo
Solución al Ejercicio 4: 1-A, 2-K, 3-M, 4-D, 5-L, 6-E, 7-G, 8-N, 9-H, 10-J, 11-F, 12-O,
13-I, 14-B, 15-C.

Procesos del área de Gestión del Alcance del Proyecto

Gestión del Alcance del Proyecto tiene procesos en los grupos de planificación y
monitorización y control:

Gestión del Alcance del Proyecto, que se definen así:
1. Planificar la Gestión del Alcance: Crear un plan para la gestión del alcance que
documente cómo se va a definir, validar y controlar el alcance del proyecto.
2. Recopilar Requisitos: Determinar, documentar y gestionar las necesidades y
los requisitos de los interesados para cumplir con los objetivos del proyecto.
3. Definir el Alcance: Desarrollar una descripción detallada del proyecto y del
producto (qué hay que hacer y qué no hay que hacer).
4. Crear la Estructura de Desglose de Trabajo (EDT): Subdividir los entregables y
el trabajo del proyecto en componentes más pequeños y fáciles de manejar.
5. Validar el Alcance: Formalizar la aceptación de los entregables del proyecto
que se hayan completado.
6. Controlar el Alcance: Monitorizar el estado del proyecto y del alcance del
producto, y gestionar cambios a la línea base del alcance. Para medir el
alcance se indican los porcentajes completados sobre cada cuenta de control.


de Gestión del Alcance del Proyecto:

Documentos del área de Gestión del Alcance del Proyecto
A continuación se destacan los documentos relacionados con la Gestión del

Alcance del Proyecto:

- WBS dictionary - Cost forecasts  Risk register
 Quality management plan - Schedule forecasts  Schedule data

Proyecto
 Plan de gestión de los requisitos - Pronósticos del cronograma  Datos del cronograma
 Plan de gestión del alcance  Enunciado del trabajo relativo a  Evaluaciones del desempeño del equipo

2.1. Planificar la Gestión del Alcance
Planificar la Gestión del Alcance es el proceso de crear un plan para la gestión

del alcance que documente cómo se va a definir, validar y controlar el alcance del
proyecto. El beneficio clave de este proceso es que proporciona orientación e
indicaciones sobre cómo se gestionará el alcance a lo largo del proyecto.
2.1.1. ENTRADAS
 Plan para la dirección del proyecto: Los planes secundarios aprobados del plan
para la dirección del proyecto se usan para crear el plan de gestión del alcance
e influyen en el enfoque adoptado para planificar y gestionar el alcance del
proyecto.
 Acta de constitución del proyecto: Se usa para proporcionar el contexto del
proyecto (cronograma, costes, calidad, recursos humanos, comunicaciones,
riesgos, adquisiciones e interesados). Proporciona una descripción de alto nivel
del proyecto y de las características del producto a partir del enunciado del
trabajo del proyecto.
 Factores Ambientales de la Empresa: Algunos factores que pueden influir en
este proceso:
 La cultura de la organización.
 La infraestructura.
 La gestión de personal.
 Las condiciones del mercado.


en este proceso:
 Políticas y procedimientos.
 Información histórica y base de conocimientos de lecciones aprendidas.
 Juicio de expertos: Cualquier grupo o persona con una formación,

conocimiento, habilidad, experiencia o capacitación especializada en el
desarrollo de planes para la gestión del alcance puede aportar su experiencia.
 Reuniones: El equipo del proyecto puede asistir a reuniones del proyecto para
desarrollar el plan de gestión del alcance. Dependiendo de las necesidades,
suelen asistir: el director del proyecto, el patrocinador del proyecto,
determinados miembros del equipo del proyecto, determinados interesados,
personas responsables de cualquiera de los procesos de gestión del alcance y
otras personas, etc.
2.1.3. SALIDAS
 Plan de gestión del alcance: Describe cómo será definido, desarrollado,

monitorizado, controlado y validado el alcance. Suele incluir:
 Cómo se elaborara un enunciado detallado del alcance del proyecto
detallado.
 Cómo se creará la EDT a partir del enunciado detallado del alcance del
proyecto.
 Cómo se mantendrá y aprobará la EDT.
 Cómo se obtendrá la aceptación formal de los entregables del proyecto
que se hayan completado.
 Cómo se procesarán las solicitudes de cambios relativas al enunciado
del alcance detallado del proyecto.
 Plan de gestión de los requisitos: Describe cómo se analizarán, documentarán
y gestionarán los requisitos. Suele incluir:
 El modo en que se planificarán y monitorizarán las actividades
asociadas a los requisitos.
 Las actividades de gestión de la configuración
 Comunicación de solicitudes de cambios.
 Método de análisis.
 Método de seguimiento de cambios.
 Registro y comunicación de impactos.
 Niveles de autorización para aprobar dichos cambios.
 El proceso para priorizar los requisitos.
 Métricas de producto.

 Estructura de trazabilidad: qué atributos de los requisitos se plasmarán

en la matriz de trazabilidad.
2.2. Recopilar Requisitos
Recopilar Requisitos es el proceso de determinar, documentar y gestionar las

necesidades y los requisitos de los interesados para cumplir con los objetivos del
proyecto. El beneficio clave de este proceso es que proporciona la base para definir y
gestionar el alcance del proyecto, incluyendo el alcance del producto.
Los requisitos incluyen condiciones o capacidades que el proyecto debe

cumplir o que deben estar presentes en el producto, servicio o resultado para
satisfacer un acuerdo u otra especificación formalmente impuesta. Los requisitos
incluyen las necesidades y expectativas cuantificadas y documentadas del
patrocinador, del cliente y de otros interesados.
Los requisitos deberían ser claros (medibles y comprobables), trazables,

completos, coherentes y aceptables para los interesados clave. Estos requisitos deben
recopilarse, analizarse y registrarse con un nivel de detalle suficiente que permita
incluirlos en la línea base del alcance y medirlos una vez que se inicie el proyecto. Los
requisitos constituyen la base de la EDT. La planificación del coste, del cronograma,
de la calidad y las adquisiciones, se basa en estos requisitos.

La Guía del PMBOK® distingue las siguientes categorías de requisitos:
 Requisitos de negocio: describen las necesidades de alto nivel de la

organización en su conjunto, tales como los problemas u oportunidades de
negocio y las razones por las que se ha emprendido un proyecto.
 Requisitos de los interesados: describen las necesidades de un interesado o
grupo de interesados.
 Requisitos técnicos: describen las prestaciones, funciones y características del
producto, servicio o resultado que cumplirán los requisitos de negocio y de los
interesados. Se dividen en funcionales y no funcionales:
 Requisitos funcionales: describen los comportamientos del producto.
Incluyen procesos, datos e interacciones con el producto. Ejemplos de
requisitos funcionales: "El producto debe generar una lista de recursos
disponibles añadidos al final de cada semana". "El sistema de ventas
debe poder tratar las devoluciones de mercancía sin abrir, no usadas o
defectuosas hasta 14 días después de la fecha de compra". "El sistema
debe computar los impuestos de ventas por área geográfica de las
tiendas".
 Requisitos no funcionales: complementan a los funcionales y describen
las condiciones ambientales y las cualidades necesarias para que el
producto sea eficaz. Incluyen: fiabilidad, seguridad, rendimiento, nivel
de servicio, capacidad de soporte, mantenimiento, etc. Ejemplos de
requisitos no funcionales: "El sistema se dimensionará para almacenar
6 meses de datos, y el pico de los datos de un mes desde los dos
últimos años consecutivos se usarán como una media mensual para
determinar la capacidad de almacenamiento del sistema". "El producto
operará a toda potencia en un rango de temperaturas de -15ºC a 15ºC
durante 8 horas, sin fallos".
 Requisitos de transferencia: describen capacidades temporales, tales como la
conversión de datos y los requisitos de capacitación, necesarias para pasar del
estado actual (as-is) al estado futuro (to-be).
 Requisitos del proyecto: describen las acciones, los procesos u otras
condiciones que el proyecto debe cumplir.
 Requisitos de calidad: recogen las condiciones o criterios necesarios para
validar la finalización exitosa de un entregable del proyecto o el cumplimiento
de otros requisitos del proyecto.
2.2.1. ENTRADAS
 Plan para la gestión del alcance: Define el modo en que los equipos del
proyecto han de determinar el tipo de requisitos que es necesario recoger para
el proyecto.
 Plan de gestión de requisitos: Define los procesos que se utilizarán para definir
y documentar las necesidades de los interesados.

 Plan de gestión de los interesados: Se utiliza para comprender los requisitos de

comunicación y el nivel de compromiso de los interesados a fin de evaluar y
adaptarse al nivel de participación de los interesados en las actividades
relacionadas con los requisitos.
 Acta de constitución del proyecto: Se utiliza para proporcionar la descripción de
alto nivel del producto, servicio o resultado del proyecto, de modo que se
puedan establecer requisitos detallados.
 Registro de interesados: Se utiliza para identificar a los interesados capaces de
proporcionar información acerca de los requisitos. También captura los
requisitos fundamentales y las principales expectativas que los interesados
pueden tener en relación con el proyecto.
 Entrevistas: Entrevistar a participantes con experiencia en el proyecto, a

patrocinadores y otros ejecutivos, así como a expertos en la materia, puede
ayudar a identificar y definir las características y funciones esperadas de los
entregables del producto. Las entrevistas también son útiles para obtener
información confidencial.
 Grupos focales: Reúnen a interesados y expertos en la materia, previamente
seleccionados, a fin de conocer sus expectativas y actitudes con respecto a un
producto, servicio o resultado propuesto. Un moderador capacitado guía al
grupo a través de una discusión interactiva diseñada para ser más coloquial
que una entrevista individual.
 Talleres facilitados: Sesiones focalizadas que reúnen a los interesados clave
para definir los requisitos del producto. Estos talleres se consideran como una
de las técnicas principales para definir rápidamente los requisitos
multidisciplinarios y conciliar las diferencias entre los interesados. Debido a su
naturaleza interactiva, las sesiones facilitadas bien dirigidas pueden desarrollar
la confianza, fomentar las relaciones y mejorar la comunicación entre los
participantes, lo que a su vez puede llevar a un mayor consenso entre los
interesados. Además, los problemas se pueden identificar y resolver antes y
más rápido que en sesiones individuales. A continuación se ofrecen algunos
ejemplos de talleres facilitados:
 En la industria de desarrollo de software, por ejemplo, se utilizan los

talleres facilitados conocidos como sesiones conjuntas de
desarrollo/diseño de aplicaciones (JAD, Joint Application Development).

 En el sector de fabricación, se utiliza el despliegue de funciones de

calidad (QFD, Quality Function Deployment). El despliegue de la
función de calidad (QFD) comienza con la recopilación de las
necesidades del cliente, lo que también se conoce como la voz del
cliente (VOC, Voice of the Customer). Estas necesidades se clasifican y
se ordenan por prioridad de manera objetiva, y se establecen objetivos
que permitan cumplir con ellas.
 En los métodos ágiles, los requisitos se suelen denominar historias de
usuario (user stories). Se ordenan de mayor a menor prioridad en una
pila de producto (product backlog). Se redactan de forma abierta para
invitar a la discusión cuando haya que planificar, lo más tarde posible,
las tareas asociadas al requisito. Los requisitos ágiles bien definidos
cumplen las propiedades CCC e INVEST. CCC quiere decir que cada
requisito pueda describirse en una tarjeta (Card), abierto para facilitar la
discusión (Conversation) y que se pueda probar que se ha terminado
(Confirmation). INVEST quiere decir que el requisito sea independiente
de otros (Independent), negociable, que suponga valor para los
interesados (Valuable), que se pueda estimar (Estimatable), que sea lo
suficientemente pequeño (Small) como para entregarse en una iteración
del proyecto, que típicamente dura dos semanas, y que pueda validarse
mediante pruebas (Testable).
 Técnicas grupales de creatividad: Se pueden organizar diferentes actividades

en grupo para identificar los requisitos del proyecto y del producto, por ejemplo:
 Tormenta de ideas: Se utiliza para generar y recopilar múltiples ideas
relacionadas con los requisitos del proyecto y del producto.
 Técnicas de grupo nominal: Mejora la tormenta de ideas mediante un
proceso de votación que se usa para jerarquizar las ideas más útiles, de
cara a una a tormenta de ideas adicional o para asignarles prioridades.
 Diagrama de afinidad: Permite clasificar un gran número de ideas en
grupos para su revisión y análisis. Al clasificar un requisito en una categoría
afín, se vuelve a pensar si los otros requisitos siguen encajando en esa
categoría, lo que proporciona una dinámica de refinamiento sucesivo. Son
muy conocidos los diagramas de afinidad para clasificar el tamaño funcional
de los requisitos en métodos ágiles. Entre los más conocidos están las
tallas de camisetas, el método MoSCoW y los cubos de valor:

 Análisis de decisiones con múltiples criterios: Es una técnica que utiliza

una matriz de decisiones para proporcionar un enfoque analítico
sistemático en el establecimiento de criterios, tales como niveles de riesgo,
incertidumbre y valoración, y así permite evaluar y clasificar muchas ideas.
Un ejemplo de análisis de decisiones multi-criterio (practicado en un
proyecto de voluntariado del PMI) fue la selección de Madrid como
ubicación para un congreso del PMI en España. En la decisión se
consideraron parámetros como el atractivo turístico, la facilidad de acceso
desde otra ciudad, el número de socios del PMI, etc. Puntuando cada
opción en cada eje de comparación, y dando unos pesos a cada eje, el
resultado fue que Madrid obtuvo la mayor puntuación con 28 puntos sobre
100.

 Mapa conceptual/mental: Las ideas que surgen durante las sesiones de

tormentas de ideas individuales se consolidan en un esquema único para
reflejar los puntos en común y las diferencias de entendimiento, y generar
nuevas ideas.
 Técnicas grupales de toma de decisiones: Permiten evaluar múltiples requisitos

en grupo y decidir acciones futuras. Existen diversos métodos:
 Mayoría: Decisión a la que se llega con el apoyo de más del 50% de los
miembros de un grupo.
 Pluralidad: El conjunto de personas más numeroso del grupo toma la
decisión.
 Dictadura. Una persona toma la decisión en nombre del grupo.
 Unanimidad: Decisión a la que se llega cuando todos están de acuerdo en
seguir una única línea de acción. Una forma de alcanzar la unanimidad es
la técnica de Delphi, según la cual un grupo seleccionado de expertos
responde a cuestionarios y el coordinador proporciona realimentación, sin
mencionar a los expertos, en sucesivas rondas hasta que convergen las
respuestas. En métodos ágiles se usan técnicas Delphi de banda ancha (en
reuniones presenciales cara a cara con realimentación inmediata, no hay
anonimato pero todos opinan a la vez para evitar influirse antes de votar).
Un ejemplo de técnica Delphi de banda ancha en métodos ágiles, que se
usa mucho para puntuar el tamaño de los requisitos con unanimidad, es el
juego conocido como planning pocker.

 Cuestionarios y encuestas: Son conjuntos de preguntas escritas, diseñadas

para recoger información rápidamente de un gran número de encuestados. Son
especialmente adecuados en casos de público variado, cuando se requiere una
respuesta rápida, cuando los encuestados están geográficamente dispersos y
cuando es conveniente realizar análisis estadísticos.
En ciertas ocasiones, cuando el equipo tiene un conjunto de requisitos amplio y

necesita la opinión sobre los potenciales usuarios del producto del proyecto, es
muy aconsejable utilizar el modelo de Kano. Que sirve para clasificar los
requisitos en 6 categorías:
 Obligatorios (must-have): Si no se entregan estos requisitos producen

gran insatisfacción, pero si se entregan pasan desapercibidos (p.ej., las
toallas del baño en la habitación de un hotel).
 Lineales (linear): El grado de satisfacción es proporcional al grado de
implementación (p.ej., el número de canales de TV en la habitación de
un hotel).
 Emocionantes (exciter): Si no se entregan estos requisitos pasan
desapercibidos, pero si se entregan producen alta satisfacción (p.ej.,
internet de banda ancha en la habitación de un hotel).
 Indiferentes (indifferent)
 Cuestionables (questionable)
 Contrarios (reverse)
La técnica para hacer encuestas según el modelo de Kano consiste

básicamente en plantear sobre cada requisito la pregunta funcional ¿cómo se
sentiría si el requisito se entrega? y otra pregunta disfuncional ¿cómo se
sentiría si el requisito no se entrega? Luego se utiliza una tabla de
equivalencias para traducir la respuesta a una de las categorías anteriores y
por último se analizan estadísticamente los resultados.
Normalmente se decide implementar todos los requisitos obligatorios, algunos

emocionantes y lineales, y ninguno de los contrarios o cuestionables.
 Observaciones: Proporcionan una manera directa de ver a las personas en su

entorno, y el modo en que realizan sus trabajos o tareas y ejecutan los
procesos. Son particularmente útiles para procesos detallados, cuando las
personas que usan el producto tienen dificultades para expresar sus requisitos.
La observación también es conocida por el término en inglés job shadowing.
Normalmente la realiza un observador externo, que observa al usuario mientras
éste realiza un trabajo. También puede hacerla un observador participante, que
ejecuta el trabajo para experimentar cómo se hace y así descubrir requisitos
ocultos por sí mismo.

 Prototipos: Es un método para obtener una realimentación rápida en relación

con los requisitos, mientras proporciona un modelo operativo del producto
esperado antes de construirlo. Puesto que un prototipo es tangible, permite a
los interesados experimentar con un modelo del producto final, en lugar de
limitarse a debatir en forma abstracta sobre sus requisitos. Los prototipos
sustentan el concepto de elaboración progresiva en ciclos iterativos para la
creación de maquetas o modelos (mock-ups), la experimentación por parte del
usuario, la generación de realimentación y la revisión del prototipo. Una vez
que se han efectuado los ciclos de realimentación necesarios, los requisitos
obtenidos a partir del prototipo están lo suficientemente completos como para
pasar a la fase de diseño o construcción. La creación de guiones gráficos
(storyboards) es una técnica de desarrollo de prototipos que muestra una
secuencia o navegación a través de una serie de imágenes o ilustraciones. Los
guiones gráficos se utilizan en diversidad de proyectos y sectores, tales como
el cine, la publicidad, el diseño educativo, en desarrollo ágil y otros proyectos
de desarrollo de software. En el desarrollo de software, los guiones gráficos
utilizan maquetas para mostrar flujos de navegación a través de páginas web,
pantallas u otras interfaces de usuario.
 Estudios comparativos (benchmarks): Implican cotejar las prácticas reales o

planificadas, tales como procesos y operaciones, con las de aquellas
organizaciones comparables (internas o externas) a fin de identificar las
mejores prácticas, generar ideas de mejora y proporcionar una base para medir
el desempeño.

 Diagramas de contexto: Representan visualmente el alcance del producto al

mostrar un sistema de negocio (proceso, equipamiento, sistema de
información, etc.), y sus interacciones con las personas y con otros sistemas
(actores).
 Análisis de documentos: Se utiliza para obtener requisitos mediante el examen

de la documentación existente y la identificación de la información relevante
para los requisitos. Se puede analizar una amplia variedad de documentos, por
ejemplo: planes de negocio, literatura de marketing, acuerdos, solicitudes de
propuestas, flujos de procesos actuales, modelos lógicos de datos, repositorios
de reglas de negocio, documentación de aplicaciones de software,
documentación de procesos de negocio o interfaces, casos de uso, otra
documentación de requisitos, registros de problemas/incidentes, políticas,
procedimientos y documentación normativa como leyes, códigos u ordenanzas,
etc.
2.2.3. SALIDAS
 Documentación de requisitos: Describe cómo los requisitos individuales

cumplen con las necesidades de negocio del proyecto. Los requisitos pueden
comenzar a un alto nivel e ir convirtiéndose gradualmente en requisitos más
detallados, conforme se va conociendo más acerca de ellos. Para ser
incorporados a la línea base, los requisitos deben ser no ambiguos (medibles y
comprobables), trazables, completos, coherentes y aceptables para los
interesados clave.

El formato de un documento de requisitos puede variar desde un documento

sencillo en el que se enumeran todos los requisitos clasificados por interesado
y por prioridad, hasta formas más elaboradas que contienen un resumen
ejecutivo, descripciones detalladas y anexos.
 Matriz de trazabilidad de requisitos: Vincula los requisitos del producto desde
su origen hasta los entregables que los satisfacen. La implementación de una
matriz de trazabilidad de requisitos ayuda a asegurar que cada requisito agrega
valor al negocio, al vincularlo con los objetivos del negocio y del proyecto.
Proporciona un medio para realizar el seguimiento de los requisitos a lo largo
del ciclo de vida del proyecto, lo cual contribuye a asegurar que al final del
proyecto se entreguen efectivamente los requisitos aprobados en la
documentación de requisitos. Por último, proporciona una estructura para
gestionar los cambios relacionados con el alcance del producto.
2.3. Definir el Alcance
Definir el Alcance es el proceso que consiste en desarrollar una descripción

detallada del proyecto y del producto. El beneficio clave de este proceso es que
describe los límites del proyecto, servicio o resultado mediante la especificación de
cuáles de los requisitos recopilados serán incluidos y cuáles excluidos del alcance del
proyecto. La preparación de una declaración detallada del alcance del proyecto es
fundamental para su éxito, y se elabora a partir de los entregables principales, los
supuestos y las restricciones que se documentan durante el inicio del proyecto. El
proceso continuará a medida que el proyecto progrese y se vaya descubriendo más
información (planificación gradual) hasta determinar exactamente qué está incluido en
el alcance y qué no.

2.3.1. ENTRADAS
 Plan para la gestión del alcance: Establece las actividades necesarias para
desarrollar, monitorizar y controlar el alcance del proyecto.
 Acta de constitución del proyecto: Proporciona una descripción de alto nivel del
proyecto y de las características del producto. Contiene además los requisitos
de aprobación del proyecto.
 Documentación de requisitos: Se utilizará para seleccionar los requisitos que
habrán de incluirse en el proyecto.
 Activos de los Procesos de la Organización: Algunos activos que pueden influir
en este proceso:
 Las políticas, procedimientos y plantillas para un enunciado del alcance del

proyecto.
 Los archivos de proyectos anteriores.
 Las lecciones aprendidas procedentes de fases o proyectos previos.
 Juicio de expertos: Entre los expertos que pueden contribuir con su experiencia
y conocimientos en este proceso, se encuentran:
 Otras unidades dentro de la organización.
 Consultores.
 Interesados, incluyendo clientes y patrocinadores.
 Asociaciones profesionales y técnicas.
 Grupos del sector de la actividad empresarial.
 Expertos en la materia.
 Análisis del producto: Para proyectos cuyo entregable es un producto, a
diferencia de un servicio o resultado, el análisis del producto puede constituir
una herramienta eficaz. Cada área de aplicación cuenta con uno o varios
métodos generalmente aceptados para traducir las descripciones de alto nivel
del producto en entregables tangibles. El análisis del producto incluye técnicas
tales como:
 Desglose del producto.
 Análisis de sistemas.
 Análisis de requisitos.
 Ingeniería de sistemas.
 Ingeniería del valor.
 Análisis del valor.

 Generación de alternativas: Se utiliza para desarrollar tantas opciones

potenciales como sea posible a fin de identificar diferentes enfoques para
ejecutar y llevar a cabo el trabajo del proyecto. Pueden utilizarse diferentes
técnicas de gestión, como:
 Tormenta de ideas.
 Pensamiento lateral.
 Análisis de alternativas.
 Talleres facilitados: Véase esta misma técnica en el proceso 5.2 Recopilar
Requisitos. La participación de actores clave con diversas expectativas y/o
áreas de experiencia en estas sesiones de trabajo intensivo contribuye a
alcanzar un entendimiento multidisciplinar y común de los objetivos del
proyecto y de sus límites.
2.3.3. SALIDAS
 Enunciado del alcance del proyecto: Es la descripción del alcance, de los

entregables principales, de los supuestos y de las restricciones del proyecto. El
enunciado del alcance del proyecto documenta el alcance en su totalidad,
incluyendo el alcance del proyecto y del producto. Describe de manera
detallada los entregables del proyecto y el trabajo necesario para crear esos
entregables. También proporciona un conocimiento común del alcance del
proyecto entre los interesados en el proyecto. Puede contener exclusiones
explícitas del alcance, que pueden ayudar a gestionar las expectativas de los
interesados. Permite al equipo del proyecto realizar una planificación más
detallada, sirve como guía del trabajo del equipo durante la ejecución y
proporciona la línea base para evaluar si las solicitudes de cambios o de
trabajo adicional se encuentran dentro o fuera de los límites del proyecto.
El enunciado del alcance del proyecto, ya sea directamente o por referencia a

otros documentos, incluye:
 Descripción del alcance del producto.
 Criterios de aceptación del producto.
 Entregables.
 Exclusiones del proyecto.
 Restricciones.
 Supuestos.
Principales diferencias entre acta de constitución y el enunciado del alcance:
 Diferente propósito: El acta sirve para aprobar/justificar. El enunciado

sirve para describir el alcance.
 Diferente nivel de detalle: El acta contiene información de alto nivel,
para que la alta dirección de la organización ejecutante pueda tomar la
decisión sobre si aprobar el proyecto o no. El enunciado contiene
información de detalle para consensuar el alcance entre el equipo y el
resto de interesados (a veces se denomina línea base de requisitos).

Diferente tiempo de actualización: El acta no se actualiza tras la

aprobación (salvo que haya grandes cambios, que requieran la
aprobación del patrocinador). El enunciado requiere mayor interacción
para generarse y se puede actualizar progresivamente a medida que se
produzcan cambios importantes en el proyecto.
 Actualizaciones a los documentos del proyecto: Ejemplos de documentos
susceptibles de actualización:
 El registro de interesados.
 La documentación de requisitos.
 La matriz de trazabilidad de requisitos.
2.4. Crear la EDT/WBS
Crear la EDT (Estructura de Desglose de Trabajos; en inglés WBS Work

Breakdown Structure) es el proceso de subdividir los entregables del proyecto y el
trabajo del proyecto en componentes más pequeños y más fáciles de manejar. El
beneficio clave de este proceso es que proporciona una visión estructurada de lo que
se debe entregar. Una EDT es un diagrama jerárquico, en el que los componentes de
nivel más bajo se denominan paquetes de trabajo.
Lo que no esté incluido en la EDT no forma parte del alcance y por tanto no
debe hacerse. Por el contrario, el equipo de dirección del proyecto se compromete a
gestionar todos y cada uno de los trabajos incluidos en la EDT. Una EDT correcta
cumple la regla del 100%, que dice que el total del trabajo correspondiente a los
niveles inferiores debería corresponder al acumulado para los niveles superiores, de
modo que no se omita nada y que no se efectúe ningún trabajo innecesario. Entre
otros beneficios, elaborar en la EDT permite aclarar el alcance a los interesados y fijar
sus expectativas (así como añadir o quitar entregables, ubicar esfuerzos, requisitos,
etc.)
Un ejemplo de EDT se representa a continuación. Puede apreciarse lo

siguiente: 1) las ramas no tienen por qué estar equilibradas; 2) cada nodo está
numerado según un código de cuenta; 3) los nodos terminales representan los
paquetes de trabajo; 4) ciertos nodos se marcan como cuentas de control (no todos los
nodos son cuentas de control, solo los que tenga sentido controlar, pero las cuentas
de control deben recubrir el 100% del trabajo). En esta EDT hay 4 ramas, 27 paquetes
de trabajos y 10 cuentas de control:

La EDT debe descomponerse hasta el nivel de paquetes de trabajo, que ya son

unidades de gestión que se pueden planificar, presupuestar, asignar y controlar. Como
regla informal un paquete de trabajo supondrá un esfuerzo entre a 8 y 80 horas-
persona. Según la Guía del PMBOK®, un paquete de trabajo todavía no es una
actividad con fechas (las actividades se pueden obtener descomponiendo los
paquetes de trabajo en el proceso de Gestión del Tiempo: 6.2 Definir las Actividades).
Dentro de la EDT, ciertos nodos se identifican como cuentas de control. Una

cuenta de control es un punto de control administrativo donde se integran el alcance,
el presupuesto, el coste real y el cronograma, y se utilizan en la Gestión del Valor
Ganado para la medición del desempeño. Cada cuenta de control puede incluir uno o
más paquetes de trabajo, pero cada paquete de trabajo debería estar asociado a una
única cuenta de control.
Una cuenta de control puede incluir uno o más paquetes de planificación. Un

paquete de planificación es un componente de la estructura de desglose del trabajo
bajo la cuenta de control con un contenido de trabajo conocido pero sin actividades
detalladas en el cronograma.
Una EDT normalmente se representa de forma gráfica, pero también puede

especificarse de forma textual:

Hay algunos tipos específicos de EDT orientadas a producto:
 Bill Of Materials (BOM): Se usa para representar una vista jerárquica de los
componentes y subcomponentes necesarios para fabricar un producto.
 Product Breakdown Structure (PBS): Se usa en otras áreas de aplicación
cuando él no se puede usar el término BOM.
Por último, la descripción de cada paquete de trabajo y de los elementos

necesarios para su gestión (p.ej., entregables, cuenta de cargo, hitos, responsable,
etc.) se incluye en un documento denominado diccionario de la EDT. La línea base del
alcance incluye 3 elementos: el enunciado del alcance, la EDT y el diccionario de la
EDT.
A continuación se describen las entradas, herramientas-técnicas y salidas, del

proceso 5.4 Crear la EDT:
2.4.1. ENTRADAS
 Plan para la gestión del alcance: Especifica cómo crear la EDT a partir del
enunciado detallado del alcance del proyecto y cómo se mantendrá y aprobará
la EDT.
 Enunciado del Alcance del Proyecto: Describe el trabajo que se realizará y el
trabajo que se excluirá. También enumera y describe las restricciones o
limitaciones específicas, tanto internas como externas, que pueden afectar la
ejecución del proyecto.

 Documentación de Requisitos: Permite comprender qué se debe producir como

resultado del proyecto y qué se debe realizar para entregar el proyecto y sus
productos finales.
 Factores Ambientales de la Empresa: Los estándares de EDT específicos del
sector de actividad empresarial, pertinentes a la naturaleza del proyecto,
pueden servir como fuentes de referencia externa para la creación de la EDT.
en este proceso:
 Políticas, procedimientos y plantillas de EDT.
 Archivos de proyectos anteriores.
 Lecciones aprendidas procedentes de proyectos anteriores.
 Descomposición: Se utiliza para dividir y subdividir el alcance del proyecto y los

entregables del proyecto en partes más pequeñas y manejables. El paquete de
trabajo es el trabajo definido en el nivel más bajo de la EDT para el cual se
puede estimar y gestionar el coste y la duración. El nivel de descomposición
depende del grado de control necesario para dirigir el proyecto de manera
efectiva. El nivel de detalle para los paquetes de trabajo varía en función del
tamaño y la complejidad del proyecto. La descomposición de la totalidad del
trabajo del proyecto en paquetes de trabajo generalmente implica las
siguientes actividades:
 Identificar y analizar los entregables y el trabajo relacionado.
 Estructurar y organizar la EDT.
 Descomponer los niveles superiores de la EDT en componentes detallados
de nivel inferior.
 Desarrollar y asignar códigos de identificación a los componentes de la
EDT.
 Verificar que el grado de descomposición de los entregables sea el
adecuado.
 Juicio de expertos: A menudo se utiliza el juicio de expertos para analizar la
información necesaria para descomponer los entregables del proyecto en
componentes más pequeños a fin de crear una EDT. También se puede
acceder al juicio de expertos a través de plantillas predefinidas que
proporcionan orientación sobre cómo desglosar los entregables comunes de
manera efectiva. Dichas plantillas pueden ser específicas del sector de
actividad o disciplina o pueden provenir de la experiencia adquirida en
proyectos similares.

2.4.3. SALIDAS
 Línea base del alcance: Es la versión aprobada de un enunciado del alcance,

estructura de desglose del trabajo (EDT) y su diccionario de la EDT asociado,
que sólo puede se puede modificar a través de procedimientos formales de
control de cambios y que se utiliza como base de comparación. Es un
componente del plan para la dirección del proyecto. Los componentes de la
línea base del alcance incluyen:
 Enunciado del alcance del proyecto. El enunciado del alcance del proyecto
incluye la descripción del alcance, los entregables principales, los
supuestos y las restricciones del proyecto.
 EDT: Es una descomposición jerárquica del alcance total del trabajo a
realizar por el equipo del proyecto para cumplir con los objetivos del
proyecto y crear los entregables requeridos. Cada nivel descendente de la
EDT representa una definición cada vez más detallada del trabajo del
proyecto. La EDT se finaliza una vez que se asigna cada uno de los
paquetes de trabajo a una cuenta de control y se establece un identificador
único de código de cuenta para ese paquete de trabajo. Estos
identificadores proporcionan una estructura para la consolidación jerárquica
de los costes, del cronograma y de la información sobre los recursos.
 Diccionario de la EDT: Es un documento que proporciona información
detallada sobre los entregables, actividades y planificación de cada uno de
los componentes de la EDT. Puede incluir, entre otros:
 Identificador del código de cuenta.
 Descripción del trabajo.
 Supuestos y restricciones.
 Organización responsable.
 Hitos del cronograma.
 Actividades del cronograma asociadas.
 Recursos necesarios.
 Estimaciones de coste.
 Requisitos de calidad.
 Criterios de aceptación.
 Referencias técnicas.
 Información sobre acuerdos.
 Actualizaciones a los documentos del proyecto: En caso de que se generen
solicitudes de cambios aprobadas a raíz de este proceso, es posible que sea
necesario actualizar la documentación de requisitos para incorporar tales
cambios.

3. Creación de la obs y la ram del proyecto
La Gestión de los Recursos Humanos del Proyecto incluye los procesos para
organizar, gestionar y liderar al equipo del proyecto.
El equipo del proyecto está compuesto por las personas a las que se han
asignado roles y responsabilidades para completar el proyecto.
Las personas no somos intercambiables
Muchos directores de proyectos siguen pensando con paradigmas propios de

la era industrial, que no están basados en principios. Estos paradigmas son ineficaces
para dirigir proyectos en un contexto interdependiente. Un paradigma muy presente en
nuestros días gracias a la globalización, consiste en tratar a las personas como
elementos sustituibles, como si fueran piezas de una máquina. Sin embargo, los
integrantes de un equipo no son sustituibles.
El jefe de una línea de producción ve los individualismos como amenazas. Para

estos jefes, la buena gestión implica que la producción no dependa de las personas.
No hay personas clave y se pueden sustituir como las piezas de una máquina. Contra
el riesgo del trabajador que se despide, elaboran la ilusión mental del “pool de
recursos”, que consiste en descolgar el teléfono y decir “Por favor, envíenme para
mañana una nueva Luisa Pérez, y si es posible, que sea un poco menos conflictiva,
muchas gracias.”
Por el contrario, un proyecto necesita personas clave. Si no están al principio,

al poco tiempo acaban siéndolo. Un buen Director de Proyectos fomenta y aplaude
este desarrollo personal, y por supuesto, sabe que reemplazar a Luisa por un tal
Rafael tiene un coste.

En el mejor de los casos, si Rafael entra al día siguiente de la partida de Luisa,

su productividad neta será negativa. Si se trata de un proyecto software y Luisa
producía 60 puntos-función al mes, dado su desconocimiento inicial y la penalización
sobre el rendimiento de los demás miembros del equipo, la productividad neta de
Rafael comienza siendo negativa, supongamos que produce unos -20 PF/mes. Su
tasa de productividad crecerá con el tiempo hasta ponerse al nivel de Luisa.
El área sombreada del dibujo (parecida a un triángulo) representa gráficamente

el coste de la sustitución. Si tarda tres meses, este coste es como mínimo 120 puntos-
función (como dos meses de Luisa). Es fácil imaginar el perjuicio mayor cuando la
sustitución no ocurre inmediatamente (rectángulo + triángulo).
Los profesionales discuten: Cuanto más expertos, más discuten
Si bien hay pocas certezas en esta profesión, una de las pocas que comparten
todos los directores de proyectos con experiencia es que en los proyectos se producen
muchos conflictos. Un conflicto ocurre cuando los intereses de dos o más personas
son incompatibles. Los proyectos están plagados de intereses y de interesados
dispares. Por otra parte, los miembros del equipo, esos trabajadores del conocimiento
responsables finales de que las actividades se realicen y los productos se construyan
con buena calidad, también son propensos a discutir. Atención, esto es importante:
que alguien discuta mucho no es síntoma de mal desempeño. Los profesionales
discuten. Les gusta su trabajo y defienden sus posiciones y sus decisiones. Cuanto
más expertos son, más discuten. Un director de proyectos debería preocuparse más
cuando en su equipo nadie discute, sobre todo en las fases iniciales. Si ocurre esto,
pregúntese: ¿Estarán dando el 100% de su capacidad? ¿Estarán colaborando unos y
otros? ¿Estarán verdaderamente motivados y comprometidos?
En todos los proyectos, los miembros del equipo esperan mucho del director de
proyectos. Lo mínimo que debe hacer el director de proyectos es “apantallar el ruido”
causado por los problemas externos que no deberían afectar al rendimiento del equipo
(presiones de los clientes y de la jerarquía, intereses “políticos” en el proyecto). Otra
necesidad básica que debe cubrir el director de proyectos es proporcionar las
condiciones de trabajo ideales para el óptimo desempeño, dentro de las posibilidades
(sala de trabajo, herramientas, documentación, etc.).
Esto es fácil. Lo verdaderamente difícil tiene que ver con las condiciones
psicológicas del trabajo de los miembros del equipo.
Ganar/Ganar o no hay trato
Las soluciones eficaces a los conflictos de un proyecto no se imponen, ni se

obtienen suavizando los problemas, o esperando que se arreglen solos. Es
responsabilidad del Director de Proyectos enfrentar los problemas cuanto antes, y no
dar por cerrado un conflicto hasta que todas las partes involucradas sientan que “han
ganado” con la solución.

En el famoso libro Obtenga el Sí se ofrecen muy buenas ideas para evitar la

gestión posicional de un conflicto, en favor de una negociación basada en principios,
que siempre favorecerá más al proyecto:
 Separe a las personas del problema: sea blando con los demás y duro con el
problema. Compórtese de una manera que no tenga nada que ver con la
confianza.
 Céntrese en los intereses, no en las posiciones: explore los intereses. Evite
tener un mínimo aceptable.
 Invente opciones en beneficio mutuo: desarrolle opciones múltiples entre las
que escoger; decida más tarde.
 Insista en utilizar criterios objetivos: intente alcanzar un resultado basado en
normas que sean independientes de la voluntad. Razone y permanezca abierto
a los razonamientos: ceda ante el principio, no a la presión.
Gestión de Conflictos
Cuando se presenta un conflicto, las personas eficaces no piensan en ganar a

costa del otro. En su lugar, tienen el hábito de ponerse a trabajar con la otra parte para
buscar una solución, que saben que existe, en la que todos acaben ganando, y
cuando esto no es posible, cuando en lo único que se está de acuerdo es en que no
se está de acuerdo, prefieren abortar la negociación, antes que romper la buena
relación. La vida está llena de conflictos. Un conflicto se produce porque los intereses
de las partes son incompatibles. Ante cualquier conflicto entre oponentes, tendemos a
pensar en términos del “paradigma de escasez”. Es decir, lo que uno gana, el otro lo
pierde. Las personas eficaces saben que los problemas no se resuelven tan
fácilmente. Las soluciones rápidas, generalmente no son soluciones duraderas. Las
personas eficaces suelen afrontar los conflictos desde el “paradigma de la
abundancia”. En la era del trabajador del conocimiento, donde solo se dispone de
información parcial, siempre hay una solución mejor a la que cada oponente pudiera
llegar por separado.
Muchas veces, los peores conflictos “se cuecen” dentro del equipo. Un
proyecto puede fracasar simplemente porque dos miembros del equipo no se hablan.
Generalmente, a esa solución se llega trabajando juntos, poniéndose al mismo lado de
la mesa, con el problema enfrente. Así se obtienen soluciones eficaces y duraderas.
Además, de paso, se construyen auténticas relaciones. Nada une tanto como resolver
un conflicto en el que las partes salen beneficiadas. Las personas eficaces no temen a
los conflictos. Más bien al contrario, ven los conflictos como oportunidades para sus
victorias públicas.

Existen cinco técnicas generales de resolución de conflictos:
 Suavizar (Smooth) / Adaptarse (Accommodate): Hacer énfasis en los puntos de

acuerdo en lugar de las diferencias, y ceder en la postura propia frente a las
necesidades de otros para mantener la armonía y las relaciones.
 Consensuar (Compromise) / Conciliar (Reconcile): Buscar soluciones que
aporten cierto grado de satisfacción a todas las partes a fin de resolver el
conflicto de manera temporal o parcial.
 Retirarse (Withdraw) / Eludir (Avoid): Retirarse de una situación de conflicto
real o potencial, posponer el problema para estar mejor preparado o para que
lo resuelvan otros.
 Forzar (Force) / Ordenar (Direct): Imponer el punto de vista propio a costa de
los demás, ofreciendo únicamente soluciones de tipo ganar-perder, y
generalmente hacerlas cumplir mediante uso de una posición de poder para
resolver una emergencia.
 Colaborar (Collaborate) / Resolver el Problema (Problem Solve): Incorporar
múltiples puntos de vista y visiones desde diferentes perspectivas; requiere una
actitud colaboradora y un diálogo abierto que normalmente conduce al
consenso y al compromiso.
La Cuenta Bancaria Emocional
El director de proyectos debe invertir muchos fondos en la cuenta bancaria

emocional de cada uno de los miembros del equipo. Hay que escucharles
empáticamente hasta comprenderles bien, prestar atención a las pequeñas cosas,
mantener las promesas, clarificar las expectativas, ser un modelo de integridad. El
paradigma de la cuenta bancaria emocional, propuesto por Stephen R. Covey, es una
forma excelente de representar la confianza que los miembros del equipo pueden
tener en el director de proyectos. El director de proyectos debería medir,
metafóricamente hablando, los depósitos y las retiradas de fondos “emocionales” en
las personas del equipo.

Cuando le dedicamos tiempo a alguien, cuando le escuchamos, cuando

hacemos algo por ellos, estamos haciendo depósitos en la cuenta emocional con esa
persona. Cuando les pedimos que hagan algo por nosotros, sin darles explicaciones,
cuando quieren hablar con nosotros y no tenemos tiempo, cuando les pedimos un
sobre-esfuerzo, estamos retirando fondos. Es muy importante saber cuándo estamos
en números rojos con determinada persona porque no nos dejará hacer más
reintegros. A diferencia de las cuentas bancarias normales, para cuadrar una cuenta
bancaria emocional hay que hacer pequeños depósitos continuamente.
Si ha invertido en las personas del equipo suficientes fondos, cuando se

produzca un conflicto entre ellos, un conflicto real que perjudique al proyecto, entonces
podrá resolver el problema con ellos de una forma efectiva.
Si su equipo no está capacitado para el proyecto, usted fracasará
El director del proyecto depende totalmente de su equipo. No debe hacer el

trabajo, sino dirigir el trabajo, se parece a un director de orquesta. Le corresponde al
equipo del proyecto realizar efectivamente el trabajo del proyecto. El director del
proyecto debe decir qué y cuándo. Al principio, quizá deba realizar algunas tareas,
orientar estrechamente a su gente, pero la aspiración es que al final se consolide un
equipo sinérgico y autosuficiente en el que pueda delegar todos los trabajos, para
centrarse en la pura gestión. Que aparezca un equipo sinérgico no se puede
garantizar. El director del proyecto no hace que ocurra, sino que deja que ocurra. Es
algo que depende de ellos. Por supuesto, si un miembro del equipo no encaja, hay que
reemplazarle por otro. Pero una vez que ha decidido que no habrá más cambios, que
ese es su equipo de proyecto, la mejor táctica es confiar en ellos. El director de
proyectos debe saber que no puede protegerse ante la incompetencia de su propio
equipo.
¿Aumentar la presión y exprimir al equipo?
Muchos directores de proyectos piensan que hay que controlar estrechamente

a los miembros del equipo, creen que producirán mejor trabajo si les hacen sentir una
presión permanente, desde el principio. Se consideran mejores gestores cuantas más
horas consigan del equipo (por supuesto, no remuneradas). Empiezan a sentirse
satisfechos cuando se trabaja también algunos fines de semana.
¿Y si a estas personas les gusta su trabajo? Estar encima del trabajador,

pendiente de si trabaja o no, azuzándole continuamente, puede ser beneficioso en un
restaurante de comida rápida, no lo es para dirigir un trabajo intelectual. Un toque de
atención hace que la gente se active, pero no consigue que piensen mejor ni más
rápido.

Ciertos estudios sobre proyectos de software demuestran que, por encima de

un cierto límite, trabajar más horas no aumenta la productividad neta. Cuando se
rebasan las 120 horas a la semana, la productividad llega a ser incluso negativa (el
trabajo efectivo es inferior al retrabajo). Hay una franja de productividad óptima entre
60-80 horas a la semana, pero nadie puede trabajar continuamente mucho más de 40
horas, no al ritmo e intensidad que requiere el trabajo creativo. La gente bajo presión
no piensa más deprisa.
La presión enérgica ocasional y las horas extra pueden ser tácticas útiles
porque mantienen a la gente enfocada e incrementan el sentido de que el trabajo es
importante, pero la presión prolongada es siempre un error. Se ha comprobado que las
horas extra (overtime en inglés), se compensan con menos horas productivas,
undertime (por ejemplo, a un domingo de trabajo le sigue un lunes relajado, si por la
noche se trabaja, la mañana es improductiva con reuniones inacabables). Como estas
horas extra no se pagan, el overtime no aparece en los registros de incurridos. Igual
de invisible resulta el undertime, pero es razonable asumir una correspondencia de
una hora de undertime por cada hora de overtime.
Algunos autores comparan el overtime con esprintar en una carrera. Esprintar

tiene sentido los últimos 100 metros de la maratón (para aquellos que les queden
fuerzas), pero no se recomienda comenzar esprintando desde el primer kilómetro.
Obligar a las personas a esprintar tanto solo conduce a que le pierdan el respeto al
jefe. Los buenos trabajadores ya han pasado por ello, saben lo suficiente para guardar
silencio mientras el jefe despotrica sobre que el trabajo hay que terminarlo en una
fecha límite imposible de cumplir. Ya tomarán su undertime compensatorio cuando
puedan y así el balance final será de 40 horas de trabajo efectivo a la semana, muy
probablemente. Terrible sospecha: muchos directores de proyectos no usan el
overtime para terminar el trabajo a tiempo sino para protegerse, para evitar que les
acusen cuando el proyecto inevitablemente fracasa.

Gestionar a las personas por objetivos
Las personas asignadas a un proyecto no deberían gestionarse como si fueran

trabajadores de una línea de montaje de una planta de producción industrial. Controlar
cuántas horas trabajan, presionar para que trabajen más horas no remuneradas,
ponerles mala cara cuando llegan tarde o se van antes que nosotros, imponer nuestro
criterio sin darles explicaciones, decidir por ellos, “mostrar los galones” para que
obedezcan ciegamente, etc. Todo esto no sirve para que trabajen mejor. El trabajo que
deben desarrollar estos “trabajadores del conocimiento” es de tipo intelectual.
Presionando no conseguiremos que piensen más rápido o mejor. Los miembros del
equipo que sobresalen, esos que son la razón de nuestro éxito, se motivan
principalmente por su crecimiento profesional, que solo es posible si: 1) su trabajo
tiene un sentido para ellos, es decir, los objetivos a corto y medio plazo les son
significativos; y 2) mantienen un alto grado de autocontrol en su trabajo. Si les
“robamos” gran parte de autocontrol, o si no “compran” los objetivos, entenderán que
sus posibilidades de crecer se reducen, y entonces ya no hacen voluntariamente lo
que queremos: ya no nos siguen.
Cuando empecé a dirigir proyectos, yo pensaba que mi trabajo consistía en

controlar todo lo que hacían los miembros del equipo, mientras que su trabajo
consistía en hacerlo todo tal y como yo pedía. Como mi mayor experiencia era en
programación de software, mi forma de gestionar a las personas era como si el
proyecto fuera un sistema de información a desarrollar, y las personas fueran módulos
con interfases: Pepe y Juan colaboran para generar tal entregable, que con este otro
de Pedro, Antonio genera un entregable mayor, yo lo reviso y entrego una primera
versión al cliente para su revisión. Para que no se equivocaran, yo tomaba todas las
decisiones y ellos esperaban mis instrucciones. Había poco desarrollo individual y
colectivo. En aquella época no tuve verdaderos equipos proactivos, cohesionados y
eficaces. El más ineficaz de todos era yo mismo, incapaz de delegar: para ser eficaces
tenemos que gestionar por objetivos.
La parte fácil de gestionar por objetivos es el seguimiento. Se supone que la

persona está comprometida y hace lo que debe hacer, y si no, hay evidencias que
demuestran que el objetivo no se está cumpliendo. Aquí hay que tener cuidado:
Kenneth Blanchard nos previene contra los peligros del refuerzo negativo. Muchos
jefes ponen objetivos y esperan a que el subordinado cometa un error para
reprenderle. El refuerzo negativo es lo primero que hacen. Esto es un error: se les
impide crecer en esa asignación. Es como enseñar a un niño a caminar. Si la primera
vez que se cae hacemos un drama, al niño le costará mucho más aprender porque
tendrá miedo de volver a caerse. Por el contrario, si cuando se cae no decimos nada,
pero le hacemos una fiesta la primera vez que da dos pasos seguidos, entonces sí
aprenderá rápido. Con los miembros del equipo es igual: hay que esperar a que
tengan su primer éxito y entonces felicitarles explicándoles por qué nos gusta lo que
han hecho bien (según Blanchard, en esto se tarda un minuto). Estos breves refuerzos
positivos contribuyen notablemente a que aumenten su confianza y su zona de control.

Por supuesto, si hacen algo mal, hay que reprenderles, pero antes ya hemos
de haberles felicitado en esa asignación, al menos una vez.
La parte más difícil de gestionar por objetivos, es plantearlos y acordarlos.

Stephen Covey propuso un esquema de cinco pasos: 1) acordar los resultados
deseados; 2) indicar directrices o rangos de actuación; 3) identificar los recursos
disponibles; 4) explicitar los mecanismos de seguimiento y evaluación y 5) clarificar las
consecuencias del buen o mal desempeño. Otro consejo de Kenneth Blanchard al
definir objetivos: escribirlos en una hoja para que puedan releerse en un minuto.
La paradoja del control: para mantenerlo, hay que cederlo
El principal beneficio de la gestión por objetivos es que las personas asumen el

control. La cuestión del control tiene que ver primero con la elección de los métodos
para hacer el trabajo. Podríamos creer que es nuestra responsabilidad seleccionar
cómo cada tarea debe realizarse. Pero si obligamos a usar ciertos métodos, entonces
ya no podremos responsabilizar a las personas cuando no consigan los objetivos. La
excusa, cierta o no, será que los métodos que les hemos impuesto no han funcionado.
Es básico que la gente use sus propios métodos. Aquí podemos orientar, pero no
obligar. Por otra parte, para que se sientan libres, hay que darles libertad de acción
para que tomen sus propias decisiones y cometan sus propios errores. Los errores son
importantes. Si el control que les damos es para que cometan los mismos errores que
habríamos cometido nosotros, entenderán que no tienen verdadero control. Tampoco
podremos responsabilizarles por no cumplir los objetivos.
Así pues, para que los demás se salgan con la nuestra, hay que gestionar por
objetivos, pero observen la paradoja del control: para mantener el control, hay que
cederlo. Uno tiene que usar su autoridad con precaución para que no se note que la
está usando. Hay que crear una sensación auténtica de que el control no está
centralizado en nuestras manos, sino distribuido generosamente entre los miembros
del equipo.
Como el timonel experimentado, que sabe que al usar el timón se pierde

velocidad, hay que dirigir con la mínima intervención posible. Otra analogía válida es el
deporte de la esgrima, donde se dice que hay que aprender a sujetar el florete como si
fuera un pájaro: si se sujeta muy fuerte, el pájaro se ahoga, si se sujeta muy flojo, el
pájaro vuela.
Apreciar las diferencias
Un equipo no será eficaz si no es completo y equilibrado. El conocimiento

necesario para abordar las tareas puede estar repartido (ignorancia y conocimiento se
compensa entre unos y otros), pero además, entre todos deben tener suficiente
afinidad para colaborar eficazmente y suficiente disciplina como para lograr que las
cosas se hagan.

Un director de proyectos no puede forzar que el equipo acabe siendo

cohesionado y sinérgico, pero sí puede plantar buenas semillas buscando que los
miembros del equipo no solo estén capacitados en su conjunto, sino que además
tengan disposición para obtener los resultados y colaborar. Si los miembros de un
equipo son homogéneos, uniformes, equivalentes, quizá sean todos demasiado
buenos (y compitan demasiado), quizá sean demasiado malos (y nadie lo note). Los
proyectos en general, y especialmente aquellos que asumen grandes riesgos, salen
beneficiados si hay diversidad en conocimientos, caracteres sociales distintos y
diferente orientación a la acción.
Un director de proyectos debe preferir las diferencias en las personas, antes

que la uniformidad, porque es más probable que así el equipo resulte más equilibrado.
Que un equipo esté equilibrado no garantiza que sea eficaz, pero lo contrario sí suele
ser cierto: un equipo no será eficaz si no está completo y equilibrado. Por otra parte,
mientras el equipo se desarrolla (lo cual depende más de ellos que del director de
proyectos), aparte de proporcionar las condiciones ambientales idóneas para que el
equipo trabaje bien (procurar una sala y equipamiento, motivar, clarificar objetivos,
apantallar problemas innecesarios, etc.), el director de proyectos debería monitorizar si
el equipo está completo, o falta que algún componente asuma otro rol.
Se ha escrito mucho sobre los distintos roles que suelen aparecer cuando la
gente trabaja en equipo. Hay muchos test psicológicos que sirven para clasificar a las
personas. Algunos directores de proyectos tienen el paradigma de que si saben cómo
etiquetar a una persona, entonces saben qué se puede hacer para manipularla,
dirigirse a él o ella en una comunicación, o bien cómo elogiar sus fortalezas o criticar
sus debilidades. A mi juicio, hay que tener mucho cuidado con estos enfoques porque
no suelen ser eficaces a la hora de gestionar proyectos.
Por ejemplo, imaginemos que alguien es del tipo “azul” según la teoría de
concienciación relacional. Según esta teoría, a esta persona le motivará la protección,
el crecimiento y el bienestar de los demás. Si es “rojo”, le motivará completar las
tareas y que la gente consiga los resultados propuestos. Si es “verde” se preocupará
de que los métodos seguidos sean los correctos. Entonces, cuando nos
comuniquemos con un “azul” hay que hablarle de lo que las personas van a conseguir
y aprender. Si hablamos con un “rojo” hay que hablarle del plan de acción. Si
hablamos con un “verde” hay que hablarle de la metodología a utilizar. ¡Ojalá fuera tan
sencillo!
Yo creo que está bien saber de qué tipo son las personas con las que
trabajamos en un proyecto, esto nos ayuda a comprender sus comportamientos y
motivaciones. También es bueno hacer autoanálisis para conocernos a nosotros
mismos. La pregunta clave es si etiquetar a la gente sirve de algo a la hora de entregar
los proyectos en plazo, coste, alcance y calidad. Un proyecto es un sistema natural (no
artificial), que sigue la ley de la cosecha. Con los miembros de un equipo no hay
recetas rápidas. Con las personas, deprisa es lento y lento es rápido.

El paradigma de “Equipo Completo”
Lo que sí debería saber un director de proyectos es si su equipo está completo

y equilibrado o de lo contrario necesita cubrir alguna carencia. Quizá esto sí esté en su
alcance de gestión. Utilizando la analogía del paradigma de “Persona Completa”, el
paradigma de “Equipo Completo” debería cubrir los 4 tipos de inteligencia:
 Resultados (inteligencia física): orientación a resultados. Disciplina y

perseverancia para conseguir que las cosas se hagan.
 Habilidades (inteligencia mental): orientación al conocimiento. Contar con la
capacitación y habilidades necesarias para desarrollar los trabajos.
 Colaboración (inteligencia emocional): orientación a la colaboración entre las
personas. Saber entenderse y coordinarse para trabajar en equipo.
 Transcendencia (inteligencia espiritual): orientación a la transcendencia del
equipo en la organización. Llegar a ser un todo sinérgico capaz de auto-
gestionarse y repetir la excelencia si el equipo tiene oportunidad de volver a
trabajar juntos en otro proyecto.
El psicólogo inglés, el doctor Raymond Meredith Belbin, en su libro

“Management Teams” concluyó experimentalmente que los miembros de un equipo
eficaz deberían cubrir 9 roles al gestionar y ejecutar los trabajos:
 Roles orientados al conocimiento: cerebro, monitor-evaluador, especialista.

 Roles orientados a la acción: impulsor, implementador, finalizador.
 Roles orientados a las personas: coordinador, cohesionador, investigador de
recursos.

Belbin no propone ningún rol orientado a la “transcendencia del equipo”, pero

esta clasificación ya es suficientemente útil para que un director de proyectos analice
si su equipo es completo y equilibrado, y a partir de este conocimiento, utilice su mejor
juicio para tomar decisiones y obrar en consecuencia.
En la tabla de la página siguiente se incluye una breve descripción de cada uno

de estos nueve roles de Belbin, indicando su principal contribución, así como sus
principales puntos débiles.

Tipos de poder
Un director de proyectos puede ejercer distintos tipos de poder para influir o

controlar el comportamiento de los miembros del equipo:
 Poder legítimo: El director de proyecto tiene este poder por la posición que
ocupa en el proyecto. Los miembros del equipo obedecen las órdenes del
director del proyecto porque saben que el director del proyecto tiene la
autoridad para dar órdenes. El poder legítimo proviene de la posición formal de
la persona dentro de la organización. El director del proyecto puede usar este
poder por su posición en la jerarquía de la organización y por la autoridad
sobre el proyecto otorgada por la organización ejecutora. Se recomienda usar
este poder conjuntamente con el poder experto y de recompensa, siempre que
sea posible.
 Poder coercitivo: Los miembros del equipo obedecen al director del proyecto
por miedo a las consecuencias de no hacer lo que pide y de la manera en que
lo pide. Este tipo de poder solo funciona en algunos casos.
 Poder referencial: Si el director del proyecto está bien relacionado con la alta
dirección, o tiene algún tipo de conexión con algunas personas influyentes en
la organización, se dice que el director del proyecto tiene un poder referencial.
Este tipo de poder no suele durar en el tiempo.

 Poder por recompensa: Los miembros del equipo porque piensan que el
director del proyecto es capaz de recompensarles para premiar su buen
desempeño. La recompensa puede ser económica (incremento salarial, bonos,
promoción, etc.) o de otro tipo (desarrollo profesional, carta de recomendación,
días de vacaciones, etc.).
 Poder experto: Los miembros del equipo respetan al director del proyecto por
su solidez técnica en la materia. Confían en él y obedecen sus órdenes porque
piensan que el director del proyecto es un experto, tiene un conocimiento
especial sobre la materia, y sabe cómo resolver los problemas.
Habilidades Interpersonales para el Director de Proyectos
 Liderazgo (Leadership): En general, el liderazgo es la capacidad de lograr que

las cosas sean realizadas a través de otras personas. Los elementos clave de
un liderazgo eficaz son el respeto y la confianza, más que el miedo y la
sumisión. Si bien el liderazgo es importante durante todas las fases del
proyecto, un liderazgo eficaz resulta esencial durante las fases iniciales del
proyecto, cuando se pone énfasis en comunicar la visión y en motivar e inspirar
a los participantes del proyecto para alcanzar un alto desempeño.
 Desarrollo del Espíritu de Equipo (Team Building): Consiste en ayudar a un
grupo de personas, unidas por un mismo objetivo, a trabajar unos con otros,
con el líder, los interesados externos y la organización. Para que el desarrollo
del espíritu de equipo sea óptimo es preciso obtener el respaldo de la
dirección, fomentar el compromiso de los miembros del equipo, proponer
recompensas apropiadas, dar muestras de reconocimiento, regirse por la ética,
crear una identidad de equipo, gestionar los conflictos con eficacia, promover la
confianza y la comunicación abierta entre los miembros del equipo y ejercer el
liderazgo.
 Motivación (Motivation): En un proyecto, la motivación implica la creación de un
ambiente de proyecto que cumpla con los objetivos del proyecto, y que a la vez
ofrezca una satisfacción máxima relacionada con lo que las personas más
valoran. Estos valores pueden incluir la satisfacción profesional, un trabajo
estimulante, una sensación de realización, logro y crecimiento, una
compensación financiera suficiente, y otras recompensas y reconocimientos
que la persona considera necesarias e importantes.
 Comunicación (Communication): Es esencial que exista una comunicación
eficaz dentro del equipo del proyecto y entre el director del proyecto, los
miembros del equipo y todos los interesados externos. Un componente
importante de las comunicaciones consiste en escuchar. Las técnicas para
escuchar, tanto activas como pasivas, proporcionan al usuario una
comprensión profunda de las áreas problemáticas, de las estrategias de
negociación y gestión de conflictos, de la toma de decisiones y de la resolución
de problemas.

 Influencia (Influencing): Consiste en compartir la autoridad y apoyarse en las

habilidades interpersonales para hacer que otros cooperen en la consecución
de metas comunes. El uso de las siguientes pautas puede influenciar a los
miembros del equipo: 1) Dirigir con el ejemplo y cumplir cabalmente los
compromisos. Aclarar la forma en que se va a tomar una decisión. 2) Utilizar un
estilo interpersonal flexible y adaptarlo de acuerdo con la audiencia. 3) Ejercer
el poder con habilidad y cautela. Buscar relaciones de colaboración a largo
plazo.
 Toma de Decisiones (Decision making): Existen cuatro estilos básicos de toma
de decisiones que los directores de proyecto utilizan normalmente: ordenar,
consultar, consensuar y aleatorio. Existen cuatro factores principales que
afectan el estilo de la toma de decisiones: las restricciones de tiempo, la
confianza, la calidad y la aceptación. Los directores de proyecto pueden tomar
decisiones individualmente o hacer que el equipo de proyecto participe en este
proceso.
 Conocimientos Políticos y Culturales (Political and Cultural awareness): El uso
hábil de la política y el poder ayudan al director del proyecto a tener éxito. Las
diferencias culturales pueden ser tanto de naturaleza individual como
corporativa, y pueden involucrar a interesados internos y externos. La cultura a
nivel del comportamiento incluye aquellas conductas y expectativas que son
independientes de la geografía, la herencia étnica o los idiomas comunes o
diferentes. La cultura puede impactar en la rapidez del trabajo, el proceso de
toma de decisiones y la disposición a actuar sin una planificación apropiada.
 Negociación (Negotiation): Consiste en dialogar con las partes que tienen
intereses compartidos u opuestos, con el propósito de lograr un compromiso o
llegar a un acuerdo. La negociación es una parte integral de la dirección de
proyectos y, bien realizada, incrementa las probabilidades de éxito del
proyecto.
 Generar Confianza (Trust building): La capacidad de generar confianza en el
equipo del proyecto y en otros interesados clave es un componente crítico para
el liderazgo eficaz del equipo. La confianza está asociada a la cooperación, el
intercambio de información y la resolución eficaz de los problemas. Sin
confianza resulta difícil establecer las relaciones positivas necesarias entre los
diversos interesados involucrados en el proyecto. Cuando se pone en peligro la
confianza, las relaciones se deterioran, las personas se desvinculan y la
colaboración se vuelve más difícil, incluso imposible.
 Gestión de Conflictos (Conflict Management): Los conflictos resultan inevitables
en cualquier proyecto. Los requisitos incongruentes, la competencia por los
recursos, la ruptura de las comunicaciones y muchos otros factores podrían
tornarse fuentes de conflicto. Gestionar los conflictos en un proyecto implica
generar la confianza necesaria para que todas las partes involucradas sean
transparentes y honestas, y ocuparse de buscar una resolución positiva a la
situación que crea el conflicto. Los directores de proyecto se esfuerzan por
establecer un enfoque de colaboración entre los miembros del equipo
involucrados con el fin de resolver completamente los problemas.

 Coaching: Consiste en ayudar a las personas a reconocer su potencial a través

de la atribución de poder y su desarrollo. Puede ser un poderoso motivador
para los equipos. Conforme los equipos desarrollan sus habilidades,
capacidades y confianza, aumenta su disposición para enfrentar tareas
desafiantes o exigentes. Esto puede llevar a equipos más eficaces y
productivos. El coaching difiere del asesoramiento: El asesoramiento se centra
en abordar situaciones en las que los miembros del equipo “dejarán de hacer”
algo, más que cuando “no saben hacerlo.”
Liderazgo Adaptado a la Situación
Tradicionalmente ha habido dos estilos de liderazgo: el líder democrático

(orientado a las personas) y el líder autoritario (orientado a los resultados). En 1972,
los autores Paul Hersey y Kenneth Blanchard publicaron su libro Management of
organizational behavior: utilizing human resources (que ya va por su décima edición)
con la interesante idea de que el liderazgo es efectivo si se adapta al nivel de madurez
del equipo. Es decir, no hay un estilo de liderazgo mejor que otro, sino que hay que
adaptar el estilo de liderazgo a la capacidad del equipo a la hora de obtener resultados
y responsabilizarse de las tareas.
Si se mide la implicación del líder en las tareas (eje horizontal directive

behavior: comportamiento directivo, dirigir cómo se hace cada tarea para obtener los
resultados) y por otro lado se mide la consideración por las personas (eje vertical
supportive behavior: ayudar a las personas para que se desarrollen), la teoría nos dice
que hay un camino secuencial (si hay un retroceso hay que pasar por las fases otra
vez). El líder debe utilizar cuatro estilos desde que el equipo se asigna hasta que el
equipo se hace autosuficiente:

 Directing (telling): el líder orienta a cada persona en su asignación particular.

Les dice cómo hay que hacer las tareas, entrando al nivel de detalle necesario,
sin entretenerse a explicar por qué ni para qué.
 Coaching (selling): el líder sigue muy involucrado en las tareas, pero ahora no
da inmediatamente las respuestas, sino que espera que las personas las
deduzcan por sí mismas. Le interesa que las personas asuman un rol
especializado dentro del equipo, que comprendan por qué y para qué hay que
hacer las cosas.
 Supporting (participating): el líder se distancia de las tareas, pero no de las
personas, que saben que pueden contar con él cuando le necesiten.
 Delegating: el líder puede delegar completamente. No toma decisiones sobre
las tareas y confía plenamente en que el equipo sabrá resolver los problemas.
Etapas de desarrollo del equipo
Según la escalera de Tuckman, las fases del desarrollo del equipo (team
building) son cinco:
 Formación (forming): Se reúne el equipo y se informa acerca del proyecto y de

cuáles son sus roles y responsabilidades formales. Los miembros del equipo
tienden a actuar de manera independiente y no demasiado abierta.
 Turbulencia (storming): El equipo comienza a abordar el trabajo del proyecto,
las decisiones técnicas y el enfoque de dirección del proyecto. Si los miembros
del equipo no colaboran ni se muestran abiertos a ideas y perspectivas
diferentes, el ambiente puede tornarse contraproducente.
 Normalización (norming): Los miembros del equipo comienzan a trabajar
conjuntamente y a ajustar sus hábitos y comportamientos para apoyar al
equipo. Comienzan a confiar unos en otros.

 Desempeño (performing): Los miembros del equipo funcionan como una

unidad bien organizada. Son interdependientes y afrontan los problemas con
eficacia y sin complicaciones.
 Disolución (adjourning): El equipo completa el trabajo y se desliga del proyecto.
Esto sucede normalmente cuando se libera al personal del proyecto, al estar
completos los entregables o como parte del proceso 4.6 Cerrar el Proyecto o
Fase.
Obsérvese que las cuatro fases del liderazgo situacional (directing, coaching,
supporting, delegating) concuerdan con las cuatro primeras etapas de la escalera de
Tuckman (formación, turbulencia, normalización y desempeño):
 Mientras el equipo está en formación, el estilo de liderazgo más propicio es

directing.
 Cuando el equipo está en fase de turbulencia, el estilo de liderazgo más
recomendable es coaching.
 En la etapa de normalización, el estilo de liderazgo aplicable es supporting.
 Por último, cuando el equipo está en desempeño, al líder le corresponde
delegar.
Teorías Motivacionales
Entre las teorías motivacionales más conocidas, están las tres siguientes:
Jerarquía de necesidades de Maslow, teoría de la motivación de Herzberg, y teoría X e
y teoría Y de McGregor.
Jerarquía de necesidades de Maslow:
Maslow ideó una ayuda visual para explicar su teoría, que llamó “jerarquía de
necesidades”, consistente en una pirámide que contiene las necesidades humanas,
psicológicas y físicas. Subiendo escalón a escalón por la pirámide, se llega a la
autorrealización.

1. En la base de la pirámide se encuentran las “necesidades básicas” o

“necesidades fisiológicas”, que incluyen la alimentación (comer y beber), la
respiración, la eliminación (orinar, defecar, sudar, etc.), el descanso y el sueño
y, en general, el mantenimiento involuntario e instintivo de las funciones
corporales que hacen posible la vida.
2. El siguiente nivel es el de las “necesidades de seguridad y protección”:
seguridad, orden y estabilidad. Los dos primeros escalones son importantes
para la supervivencia de la persona. Una vez que los individuos tienen
satisfecha su nutrición, cobijo y seguridad vital, tratan de satisfacer otras
necesidades.
3. El tercer nivel es el de “necesidad de amor y pertenencia”, compuesto por
necesidades psicológicas: cuando los seres humanos han cuidado de sí
mismos físicamente, están listos para compartirse a sí mismos con otros.
4. El cuarto nivel se alcanza cuando los individuos se sienten cómodos con lo que
han conseguido; este es el nivel de “necesidad de estima”, que incluye el éxito
y el estatus, fundamentalmente en la percepción propia (autoestima), aunque
también en la percepción que los demás le transmiten.
5. La cima de la pirámide es la “necesidad de autorrealización”, y se supera
cuando se alcanza un estado de armonía y entendimiento.
Teoría de la motivación de Herzberg: Según esta teoría, las personas están

influenciadas por dos tipos de factores:
 Factores motivacionales (motivan si están cubiertos, son positivos y de carácter

interno): Reconocimiento, crecimiento personal, responsabilidad, promoción,
logros, independencia laboral, madurez, consolidación, etc.
 Factores higiénicos (desmotivan si no están cubiertos, son negativos y de
carácter externo): condiciones salariales, política de la empresa y su
organización, relaciones con los compañeros de trabajo, ambiente físico,
supervisión, estatus, seguridad laboral, etc.
Teoría X e y teoría Y de McGregor: Los trabajadores son vistos de dos formas

distintas por sus superiores.
 La teoría X refleja un estilo estricto y rígido de dirección que considera que las
personas son meros recursos o medios de producción que deben ser
supervisados constantemente.
 La teoría Y considera que los trabajadores pueden dirigir ellos mismos sus
esfuerzos y que son capaces de realizar sus actividades sin supervisión.

Imaginemos un director de proyectos que gestiona eficazmente los recursos

humanos. ¿Qué actividades realizaría?
Ejercicio 1. Describa cómo gestionó los recursos humanos el director del

proyecto, en ocho párrafos, usando las siguientes palabras clave:
1. Plan para la administración de personal, negociación con el gerente funcional,

departamento de recursos humanos.
2. Involucrar a los miembros del equipo en la planificación, selección del equipo
de dirección del proyecto.
3. Coubicación, matriz de responsabilidades, histograma de recursos.
4. Dirigir-delegar, liderazgo servicial, reconocimientos y recompensas, poder
experto.
5. Formación, aprovechamiento.
6. Liberación de recursos.
7. Conflicto, observación, conversación, solicitud de cambio.
8. Evaluación de desempeño.
Solución:
1. En el plan para la administración de personal, el director del proyecto expresó

claramente (pero sin indicar nombres) cuántos perfiles necesitaba y cuándo, y
cuándo serían liberados. Negoció con el gerente funcional para pre-asignar a
determinadas personas clave de su departamento que cumplían el perfil. El
departamento de recursos humanos garantizó que el resto de los recursos
solicitados estarían disponibles en las fechas convenidas.
2. El director del proyecto involucró a algunos miembros del equipo en la
planificación. Ayudaron a identificar requisitos, interesados, restricciones,
supuestos, etc. Participaron activamente elaborando la matriz de
responsabilidades, la EDT, definiendo actividades y estimando costes y plazos.
También asumieron un papel principal en la identificación de los riesgos.
Algunos miembros del equipo ya se sentían dueños de sus actividades por
haber participado en la planificación. El director del proyecto seleccionó a los
miembros del equipo que compondrían el equipo de dirección del proyecto.
3. Cuando comenzó el trabajo del proyecto propiamente, el equipo ya contaba
con el 80% de las personas. El director del proyecto aseguró que las
condiciones del entorno de trabajo fueran las idóneas, logrando co-ubicar en
una sala a todo el equipo. Todas las personas tenían claras sus funciones
desde el principio, gracias a la matriz de responsabilidades. También sabían
cómo estaba prevista la evolución de su carga de trabajo a lo largo del tiempo,
gracias al histograma de recursos.

4. El director del proyecto comenzó dirigiendo la mayoría de las actividades, pero

poco a poco fue delegando en los miembros del equipo, cada vez más
autosuficientes. El director del proyecto trató de ejercer un liderazgo servicial:
que las personas estuvieran enfocadas en sus actividades, proporcionándoles
visión, evitándoles impedimentos, etc.
A través de reconocimientos y recompensas, logró estimular el desempeño a

través del refuerzo positivo, ejerciendo un poder experto.
5. Se aseguró que se impartía formación al personal que carecía de ciertas
competencias necesarias, evaluando el aprovechamiento después.
6. Antes de liberar a los recursos, eran preasignadas a otro proyecto con dos
semanas de antelación, según dictaba el plan para la dirección de personal,
cumpliendo la política de la organización.
7. Dos personas clave del equipo tuvieron conflictos irreconciliables que
afectaban al desempeño del equipo: El director del proyecto trató observar,
conversar y mediar sin éxito. Después hizo intervenir al gerente funcional
responsable de los recursos sin mejor resultado. Lamentablemente, el director
del proyecto se vio obligado a sustituirles y aceptar las pérdidas, para lo cual
emitió la correspondiente solicitud de cambio.
8. Se aseguró de que la información sobre lo sucedido fuera tenida en cuenta en
la evaluación de desempeño de estas dos personas. De igual manera, también
envió cartas de recomendación a los responsables de las personas cuyo
desempeño había sido sobresaliente.


a la derecha.
1 Coubicación A Los miembros del equipo del proyecto que realizan actividades de dirección del proyecto tales
como la gestión del cronograma, las comunicaciones, los riesgos, etc.
2 Gestión de Conflictos B La capacidad para identificar, evaluar y manejar las emociones personales y las de otras personas,
así como las emociones colectivas de grupos de personas.
3 Inteligencia Emocional C Un documento que representa gráficamente a los miembros del equipo del proyecto y sus
interrelaciones para un proyecto específico.
4 Reglas Básicas D Un diagrama de barras que muestra la cantidad de tiempo que un recurso está programado para
trabajar durante una serie de períodos de tiempo. La disponibilidad de recursos puede estar
representada como una línea para fines comparativos. Barras contrastadas pueden mostrar el
consumo real de recursos utilizados a medida que avanza el proyecto.
5 Habilidades E Una lista documentada de los miembros del equipo del proyecto, sus roles en el proyecto e
Interpersonales información de su localización.
6 Creación de F El manejo, control y conducción de una situación conflictiva para lograr una resolución.
Relaciones de Trabajo
7 Personal de Dirección G Una cuadrícula que muestra los recursos del proyecto asignados a cada paquete de trabajo.
de Proyectos
8 Organigrama del H Capacidad para establecer y mantener relaciones con otras personas.
Proyecto
9 Equipo del Proyecto I Una estrategia en la cual los miembros del equipo del proyecto se ubican físicamente cerca, para
mejorar la comunicación, las relaciones laborales y la productividad.
10 Directorio del Equipo J Establecer vínculos y relaciones con otras personas de la misma organización o de otras
del Proyecto organizaciones.
11 Estructura de K Una asignación que puede delegarse dentro de un plan para la dirección del proyecto de modo tal
Desglose de Recursos que el recurso asignado incurre en la obligación de llevar a cabo los requisitos de la asignación.
12 Histograma de L Acuerdo del equipo con respecto al comportamiento aceptable de los miembros del equipo del
Recursos proyecto.
13 Responsabilidad M Un componente de la planificación de los recursos humanos que describe cuándo y el modo en
que serán adquiridos los miembros del equipo del proyecto y por cuánto tiempo serán requeridos.
14 Matriz de Asignación N Un conjunto de individuos que respaldan al director del proyecto en la realización del trabajo del
de Responsabilidades proyecto para alcanzar sus objetivos.
(RAM)
15 Plan para la O Una representación jerárquica de los recursos por categoría y tipo.
Administración de
Personal
Solución al Ejercicio 2: 1-I, 2-F, 3-B, 4-L, 5-H, 6-J, 7-A, 8-C, 9-N, 10-E, 11-O, 12-D,
13-K, 14-G, 15-M.

Procesos del área de Gestión de los Recursos Humanos del Proyecto

Gestión de los Recursos Humanos del Proyecto tiene procesos en los grupos de
planificación y ejecución:
En el capítulo 9 de la Guía del PMBOK® se describen cuatro procesos para la

Gestión de los Recursos Humanos del Proyecto, que se definen así:
 Planificar la Gestión de Recursos Humanos: Identificar y documentar los roles

dentro de un proyecto, las responsabilidades, las habilidades requeridas y las
relaciones de comunicación, así como de crear un plan para la administración
de personal.
 Adquirir el Equipo del Proyecto: Confirmar la disponibilidad de los recursos
humanos y conseguir el equipo necesario para completar las actividades del
proyecto.
 Desarrollar el Equipo del Proyecto: Mejorar las competencias, la interacción
entre los miembros del equipo y el ambiente general del equipo para lograr un
mejor desempeño del proyecto.
 Dirigir el Equipo del Proyecto: Realizar el seguimiento del desempeño de los
miembros del equipo, proporcionar retroalimentación, resolver problemas y
gestionar cambios a fin de optimizar el desempeño del proyecto.


de Gestión de los Recursos Humanos del Proyecto:

Documentos del área de Gestión de los Recursos Humanos del Proyecto
A continuación se destacan los documentos relacionados con la Gestión de los

Recursos Humanos del Proyecto:


Proyecto
 Plan de gestión de los Recursos  Lista de actividades  Enunciado del trabajo del proyecto
Humanos  Requisitos de recursos de las actividades  Listas de verificación de calidad
 Plan de gestión de los recursos humanos  Acuerdos  Mediciones de control de calidad
 Plan de mejoras del proceso  Registro de supuestos  Métricas de calidad
 Plan de gestión de las adquisiciones  Base de las estimaciones  Documentación de requisitos
 Línea base del alcance  Registro de cambios  Matriz de trazabilidad de requisitos
- Enunciado del alcance del proyecto  Solicitudes de cambios  Estructura de desglose de recursos
- EDT  Pronósticos  Calendarios de recursos
- Diccionario de la EDT - Pronósticos de costes  Registro de riesgos
 Plan de gestión de los Recursos - Pronóstico del cronograma  Datos del cronograma
Humanos  Registro de incidentes  Propuestas de los proveedores
 Plan de gestión de los requisitos  Lista de hitos  Criterios de selección de proveedores
 Plan de gestión de los riesgos  Documentos de las adquisiciones  Registro de interesados
 Línea base del cronograma  Enunciado del trabajo relativo a  Evaluaciones del desempeño del equipo
 Plan de gestión del cronograma adquisiciones  Datos de desempeño del trabajo
 Plan de Gestión del Tiempo del Proyecto  Calendarios del proyecto  Información de desempeño del trabajo
 Plan de gestión de los interesados  Acta de constitución del proyecto  Informes de desempeño del trabajo

3.1. Planificar la Gestión de Recursos Humanos
Planificar la Gestión de Recursos Humanos es el proceso de identificar y

documentar los roles dentro de un proyecto, las responsabilidades, las habilidades
requeridas y las relaciones de comunicación, así como de crear un plan para la
administración de personal.
El beneficio clave de este proceso es que establece los roles y

responsabilidades del proyecto, los organigramas del proyecto y el plan para la
administración de personal, el cual incluye el cronograma para la adquisición y
liberación del personal.
3.1.1. ENTRADAS
 Plan para la dirección del proyecto: Contiene información útil para desarrollar el
plan de gestión de los recursos humanos, como por ejemplo:
 El ciclo de vida del proyecto y los procesos que se aplicarán en cada fase.
 El modo en que se ejecutará el trabajo para alcanzar los objetivos del
proyecto.
 Un plan de gestión de cambios que describa el modo en que se
monitorizarán y controlarán los mismos.
 Un plan de gestión de la configuración que documente cómo se llevará a
cabo dicha gestión.
 Una descripción de cómo la integridad de las líneas base del proyecto
serán mantenidas.
 Las necesidades y los métodos de comunicación entre los interesados.

 Requisitos de recursos de las actividades: La planificación de recursos

humanos se basa en los requisitos de recursos de las actividades, salida del
proceso. Estimar los Recursos de las Actividades, para determinar las
necesidades de recursos humanos para el proyecto. Los requisitos
preliminares relativos a las personas necesarias y las competencias para los
miembros del equipo del proyecto se elaboran de manera gradual, como parte
del proceso de planificación de los recursos humanos.
 Factores Ambientales de la Empresa: Algunos factores ambientales que
 La cultura y la estructura de la organización.
 Los recursos humanos existentes.
 La dispersión geográfica de los miembros del equipo.
 Las políticas para la administración de personal.
 Las condiciones del mercado.
en este proceso:
 Los procesos estándares de la organización, políticas y descripción de
roles.
 Las plantillas para organigramas y descripciones de puestos de trabajo.
 Las lecciones aprendidas sobre las estructuras de la organización que han
funcionado en proyectos anteriores.
 Los procedimientos de escalamiento para la gestión de incidencias en el
equipo y en la organización ejecutora.
 Organigramas y Descripciones de cargos: Existen formatos diversos para

documentar los roles y las responsabilidades de los miembros del equipo. La
mayoría de los formatos se encuadra en alguno de los tres tipos siguientes:
jerárquico, matricial y de tipo texto. Por otra parte, algunas asignaciones del
proyecto se enumeran en planes subsidiarios para la dirección del proyecto,
tales como los planes de riesgos, de calidad o de comunicación.
Independientemente del método utilizado, el objetivo es asegurar que cada
paquete de trabajo tenga un responsable inequívoco y que todos los miembros
del equipo comprendan claramente sus roles y responsabilidades.
 Diagramas jerárquicos:
 La estructura tradicional de organigrama puede utilizarse para
representar los cargos y relaciones en un formato gráfico descendente.
 La estructura de descomposición de la organización (Organizational
Breakdown Structure -OBS-) está estructurada según los
departamentos, unidades o equipos existentes de una organización,
con las actividades del proyecto o los paquetes de trabajo enumerados
para cada departamento.

Un departamento operativo, como el de tecnologías de la información o

el de compras, puede ver todas sus responsabilidades dentro del
proyecto consultando la parte que le corresponde en la OBS.
 La estructura de descomposición de recursos (Resource Breakdown
Structure) es otro diagrama de tipo jerárquico utilizado para
descomponer el proyecto según los tipos de recursos. Por ejemplo, una
estructura de desglose de recursos puede representar todos los
soldadores y equipos de soldadura que se están utilizando en diferentes
áreas de un barco, aunque se encuentren distribuidos en las diferentes
ramas de la OBS. La estructura de desglose de recursos es útil para
realizar el seguimiento de los costes del proyecto y puede alinearse con
el sistema contable de la organización. Puede contener categorías de
recursos que no sean los recursos humanos (recursos materiales).
 Diagramas matriciales: Una matriz de asignación de responsabilidades
(RAM) se utiliza para ilustrar las relaciones entre las actividades o los
paquetes de trabajo y los miembros del equipo del proyecto. El formato
matricial muestra todas las actividades asociadas con una persona y todas
las personas asociadas con una actividad. Esto también asegura que haya
una sola persona encargada de rendir cuentas por una tarea determinada a
fin de evitar confusiones. Un ejemplo de RAM es una matriz RECI.
 Responsible (Responsable): Quien debe hacer la tarea. Puede haber
varios.
 Accountable, Approver (Encargado): Responsable de la aprobación
final. Sólo puede haber 1.
 Consulted (Consultado): Se le pregunta y se tienen en cuenta sus
opiniones.
 Informed (Informado): Se le mantiene actualizado sobre el progreso.
 Formatos tipo texto: Los documentos de descripciones de los cargos

(position descriptions) suministran información sobre aspectos tales como
responsabilidades, autoridad, competencias y cualificación.

 Otras secciones del plan para la dirección del proyecto: Aparte del plan de
RR.HH, hay otros documentos que también contienen asignaciones de
responsabilidades. Por ejemplo, el registro de riesgos enumera a los
propietarios de los riesgos, el plan de comunicación enumera a los
miembros del equipo responsables de las actividades de comunicación y el
plan de calidad designa a las personas responsables de llevar a cabo el
aseguramiento y control de la calidad.
 Creación de relaciones de trabajo (networking): Es la interacción formal e
informal con otras personas dentro de una organización, sector o entorno
laboral. Constituye una manera constructiva de comprender los factores
políticos e interpersonales que tendrán un impacto sobre la eficacia de diversas
opciones para la administración de personal. Las actividades de networking
incluyen la correspondencia proactiva, los almuerzos de negocios, las
conversaciones informales en reuniones, eventos, conferencias especializadas
y simposios.
 Teoría de la organización: Suministra información relativa a la manera en que
se comportan las personas, los equipos y las unidades de la organización. Un
ejemplo son las teorías motivacionales de Maslow, Herzberg, y McGregor.
 Juicio de expertos.
 Reuniones.
3.1.3. SALIDAS
 Plan de gestión de recursos humanos: Forma parte del plan para la dirección
del proyecto. Proporciona una guía sobre el modo en que los recursos
humanos deben ser definidos, adquiridos, dirigidos, supervisados y finalmente
liberados. Debe incluir, entre otros, los siguientes aspectos:
 Roles y Responsabilidades: Para cada perfil requerido, debería describirse
el cargo a desempeñar (position descriptions) incluyendo
responsabilidades, autoridad y competencias.
 Organigramas del Proyecto. Un organigrama del proyecto es una
representación gráfica de los miembros del equipo del proyecto y de sus
relaciones de comunicación.
 Plan para la administración del personal (staffing management plan):
Describe cuándo y cómo se cumplirán los requisitos de recursos humanos.
Se actualiza constantemente durante el proyecto, a fin de dirigir la
adquisición continua de miembros del equipo y las acciones de desarrollo.
Se deben considerar, entre otros, los siguientes conceptos:

 Adquisición de personal: Los recursos humanos ¿provendrán de la

organización misma o de fuentes externas contratadas? ¿Deberán
trabajar en un lugar centralizado o desde ubicaciones distantes?
¿Cuáles son los costes asociados con cada nivel de experiencia
necesario para el proyecto? ¿Qué tipo de asistencia pueden
suministrar el departamento de RR.HH. de la organización y los
directores funcionales al equipo de dirección del proyecto?
 Calendarios de recursos: El plan para la administración de personal

describe plazos necesarios para los miembros del equipo del
proyecto, ya sea de manera individual o colectiva, así como cuándo
deberían iniciarse las actividades de adquisición, como la
contratación de personal. Una herramienta para representar en
forma de diagrama los recursos humanos es el histograma de
recursos. Este diagrama de barras muestra la cantidad de horas que
una persona, un departamento o todo el equipo del proyecto será
requerido por semana o por mes durante el desarrollo del proyecto.
Este diagrama puede representar de forma gráfica la necesidad de
adoptar una estrategia de nivelación de recursos (si un determinado
recurso se necesita más horas que las disponibles).
 Plan de liberación del personal: Determinar el método y el

calendario de liberación de los miembros del equipo beneficia tanto
al proyecto como a los miembros del equipo. Cuando los miembros
del equipo son liberados de un proyecto, los costes asociados con
dichos recursos ya no se aplican al proyecto. La motivación mejora
cuando se planifican con anticipación transiciones graduales hacia
próximos proyectos. Un plan de desafectación de personal también
ayuda a mitigar los riesgos relativos a los recursos humanos, que
pueden ocurrir durante un proyecto o al finalizar el mismo.
 Necesidades de capacitación: Si se espera que los miembros del

equipo que se asignarán no posean las competencias requeridas,
puede desarrollarse un plan de capacitación como parte del
proyecto.
 Reconocimiento y recompensas: Los criterios claros respecto de las

recompensas y un sistema planificado para su uso ayudan a
fomentar y reforzar los comportamientos deseados. El
reconocimiento y las recompensas forman parte del proceso 9.3.
Desarrollar el Equipo del Proyecto.

 Cumplimiento: El plan para la administración de personal puede

incluir estrategias para cumplir con las normas gubernamentales
aplicables, los contratos colectivos de trabajo y otras políticas
establecidas en materia de recursos humanos.
 Seguridad: Las políticas y los procedimientos que protegen a los

miembros del equipo frente a los peligros relacionados con el
trabajo pueden incluirse en el plan para la administración de
personal, así como en el registro de riesgos.
4. Comportamiento del grupo
La Gestión del Tiempo del Proyecto incluye los procesos necesarios para
gestionar que el proyecto termine dentro del plazo previsto.
La restricción de plazo suele ser una de las más importantes en cualquier

proyecto. Aunque se tenga poca información de un proyecto, a los interesados les
parece un éxito si termina en plazo. La forma más común de representar al director de
proyectos, es la imagen de una persona controlando un cronograma. Si la principal
distinción entre operación y proyecto es que un proyecto tiene una duración prefijada,
la principal distinción entre gestión de operaciones y gestión de proyectos es que
muchas actividades de gestión de un proyecto van encaminadas a terminar en la fecha
prevista.
Gestionar el Tiempo para cumplir el objetivo de plazo
No se nos ocurriría utilizar un diagrama Gantt para gestionar un servicio

repetitivo, o unipersonal. Pensemos en el caso práctico desarrollado en el anexo I: el
proyecto traducir un libro. Si la editorial holandesa hubiera solicitado simplemente un
grupo de expertos voluntarios de PMI para traducir el libro, esto no se habría
organizado como un proyecto. Simplemente se le habrían facilitado los nombres de los
voluntarios a los que enviar los textos para traducir. Las operaciones repetitivas de
traducir, corregir, maquetar, etc., podrían contar con la involucración de los voluntarios,
pero no haría falta que trabajasen organizados como un equipo de proyecto.

Si PMI hubiera requerido información de gestión, con saber las horas

dedicadas por los voluntarios habría sido suficiente.
Sin embargo, la editorial quería todo el libro traducido para lanzarlo al mercado
a comienzos de año. Antes de eso, era muy importante que la traducción estuviera
terminada con la calidad requerida, en un plazo no superior a 3 meses (11 semanas,
para ser más exactos). Finalmente el proyecto logró terminar en plazo, pero esto no se
habría logrado si no se hubiese descompuesto el esfuerzo en partes dirigidas a lograr
los objetivos de alcance y calidad, para monitorizar después continuamente las fechas
de inicio y fin de cada una de las actividades. El equipo de voluntarios tenía claros los
trabajos a realizar en cada una de las 5 semanas de traducción, las 5 de revisión y la
última semana de integración. Cuando había retrasos se tomaban acciones
correctoras y según avanzaba el proyecto se podía visualizar si el cierre en fecha
parecía factible. Dos semanas antes de terminar, los interesados opinaban que el
proyecto iba a terminar en plazo.
Mientras se gestiona el cronograma, hay muchos beneficios intangibles,

derivados principalmente del grado conocimiento que hay que tener de una actividad
para llegar a saber cuándo debe empezar y cuándo debe terminar. Para llegar a hacer
ese pronóstico hay que saberlo todo y sobre lo que no se sepa, hay que tomar
supuestos. Para saber cuánto dura una actividad, hay que saber cuántos recursos
participarán, y esto nos sitúa cerca de conocer el coste. Para saber cuándo empiezan
las actividades, hay que saber cómo dependen de otras actividades del proyecto, o de
factores externos. Sobre cada actividad, hay información segura, pero también hay
información incierta que puede provocar retrasos, pero que se puede gestionar
proactivamente como riesgos.
Quizá el beneficio más importante sea que mientras se piensa en conjunto

sobre todo esto, el equipo de proyecto ya se está formando. Si son ellos los que
inventan las actividades, implícitamente se están comprometiendo a terminarlas en
esas fechas. Mientras se ejecuta el proyecto, un gran beneficio de representar un
cronograma actualizado (y realista) es que puede motivar mucho al equipo (todos ven
cuántos días quedan, qué actividades conducen al éxito si se superan) y es un buen
instrumento de comunicación para los interesados (si la última fecha es la fecha
planificada, o el retraso previsto ya ha sido aceptado, opinan que el proyecto está bajo
control).
Gestionar el Tiempo con herramientas de Programación de Proyectos
Afortunadamente, en este campo la gestión de proyectos ha avanzado

admirablemente. Hay herramientas que soportan todo el proceso de programación de
las actividades, calculan el camino crítico, nos permiten hacer simulaciones “qué pasa
si…”. Estas herramientas se conocen con el nombre de herramientas de planificación,
o herramientas de programación del proyecto.

Estas herramientas de planificación han podido llegar tan lejos gracias a que
las formas de representar el tiempo de un proyecto están muy estandarizadas. Por
ejemplo, si nuestro proyecto fuera preparar el desayuno, el diagrama de red “actividad
en nodo” se podría representar así:
Las herramientas de planificación permiten pintar estos diagramas

automáticamente, y de paso suelen señalar el camino crítico. De igual manera, pueden
representar el diagrama Gantt:
No menos importante, estas herramientas permiten “grabar una foto” del cronograma,
incluyendo toda la información, a esa fecha, sobre nombres de tareas, fechas,
recursos, etc.: lo que en gestión de proyectos se denomina línea base del cronograma.
Al realizar el control del proyecto, estas herramientas permiten comparar la
información real contra la línea base para calcular desviaciones y pronósticos. Si hace
falta, también permiten grabar varias líneas base y recuperarlas en cualquier
momento. Adicionalmente, estas herramientas también gestionan información de
costes, de manera que pueden gestionar la línea base de costes.

En pocas palabras, las herramientas de planificación de proyectos facilitan que

el equipo de gestión se concentre en su función de gestión: definir tareas, razonar
alternativas de programación, decidir acciones correctivas, etc. No deben en perder
tiempo con actividades de poco valor como considerar los días festivos, los días de
vacaciones de cierta persona, calcular el camino crítico, el retraso hasta la fecha,
pintar un histograma de recursos, un cronograma de hitos, recordar las horas
planificadas para un recurso un determinado día, semana, mes, etc.
En proyectos muy grandes hay personas especializadas en programar las

tareas (mejor dicho, especializadas en usar la herramienta de planificación). En
proyectos de tamaño medio, el equipo de gestión suele tener un alto dominio de estas
herramientas para planificar y hacer seguimiento de los tiempos del proyecto. La
mayoría de los directores de proyectos de hoy en día cuentan con una buena
capacitación en herramientas de programación del proyecto.
Procesos para Gestionar el Tiempo de Proyectos
La Guía del PMBOK® presenta los procesos de Gestión del Tiempo del
Proyecto de manera muy bien estructurada, con el fin de facilitar su aplicación en
proyectos grandes. El equipo de dirección del proyecto documentará sus decisiones
sobre cómo aplican los procesos y de qué manera se llevarán a cabo. Un proyecto
grande que tenga fuertes restricciones de plazo, tendría que seguir cinco procesos de
planificación secuencialmente antes de llegar a producir el cronograma del proyecto.
No obstante, la definición de las actividades, su secuenciación, la estimación de sus
recursos y de su duración, así como el desarrollo del cronograma, son procesos tan
estrechamente relacionados que muchas veces se ven como un único proceso
susceptible de ser realizado por una sola persona en un periodo de tiempo
relativamente corto. La Guía del PMBOK® distingue estos procesos porque tienen
diferentes objetivos y porque las herramientas y técnicas requeridas para cada uno de
ellos son diferentes.
A continuación se describen brevemente los procesos de Gestión del Tiempo

del Proyecto:
 Después de planificar la gestión del cronograma, se aborda el proceso 6.2

Definir las Actividades. Básicamente, consiste en transformar los paquetes de
trabajo identificados en la EDT en una lista de actividades.

 Posteriormente tendría lugar el proceso 6.3 Secuenciar las Actividades, que

consiste en ordenar la lista de actividades y obtener una representación gráfica
en un diagrama de red.
 De momento no se han tratado las duraciones, sólo las actividades y sus

dependencias. Para saber cuánto dura una tarea, es necesario pensar antes
quién la realizará, o al menos qué perfil y capacitación debe tener (e.g. un
programador sénior puede tener una productividad muy superior a uno junior).
Para eso está el proceso 6.4 Estimar los Recursos de las Actividades.

 Ahora, con la información disponible de las actividades y sus necesidades de

recursos, ya puede comenzarse a trabajar en el proceso 6.5 Estimar la
Duración de las Actividades.
 El último proceso de planificación del tiempo es el proceso 6.6 Desarrollar el

Cronograma. Al alimentar el cronograma con la información de las duraciones,
es muy probable que se obtenga un plazo superior a la fecha límite. Tras
aplicar una serie de alternativas y técnicas de compresión (o de renegociar las
restricciones, por ejemplo aumentando el presupuesto) se consigue ajustar el
cronograma a las necesidades del proyecto.
 El cronograma del proyecto y la línea base del cronograma serán elementos

clave a la hora de controlar las desviaciones, lo que ocurrirá en la fase de
monitorización y control, en el proceso 6.7. Controlar el Cronograma.

Imaginemos un equipo de dirección del proyecto que gestiona eficazmente el

tiempo. ¿Qué actividades realizaría?
Ejercicio 1. Describa cómo planificó el cronograma el equipo de dirección del

proyecto en siete párrafos, usando estas palabras clave:
1. Penalización por retrasos, método del camino crítico, herramienta de

programación.
2. Umbral de desviación, comité de seguimiento, Gantt de seguimiento,

variaciones, hitos alcanzados.
3. Definir actividades, acta de constitución del proyecto, enunciado del alcance,

EDT, diccionario de la EDT, trazabilidad, descomposición, atributos de las actividades.
4. Secuenciar actividades, dependencias, diagrama de red, lógica dura, lógica

blanda.
5. Organigrama del equipo, estructura de desglose de recursos, recursos

asociados a las actividades: recursos humanos, materiales y costes.
6. Estimar las duraciones de las actividades, juicio de expertos, estimación por

tres valores, duración más probable, duración estimada, margen del 95%.
7. Línea base del cronograma, restricciones, horas extra, límites de la

financiación, compresión del cronograma, aplicar adelantos, nivelación de recursos,
intensificación, ejecución rápida.
Solución:
1. El equipo de dirección del proyecto era muy consciente de la importante

restricción de plazo para este proyecto de seis meses: el contrato con el cliente incluía
una cláusula que le permitía aplicar una penalización de 1.000 € por cada día de
retraso. En la reunión para planificar la gestión del cronograma se decidió que se
controlaría con el método del camino crítico usando la herramienta de programación
Microsoft Project©. El cronograma se planificaría en cinco reuniones en días sucesivos
que se dedicarían, respectivamente, a definir actividades, secuenciar actividades,
estimar recursos de las actividades, determinar duraciones y desarrollar el
cronograma.
2. En esa misma reunión también se decidió que se monitorizarían especialmente

las tareas críticas y el indicador de desviación del cronograma en tiempo SV (t).
Cuando este parámetro indicase umbral de desviación superior a 5 días, se escalaría
al comité de seguimiento. En todas las reuniones de seguimiento se incluiría un
diagrama Gantt de seguimiento abarcando el periodo anterior, el periodo en curso y el
periodo siguiente, y se explicarían las variaciones y los hitos alcanzados.

3. En la reunión dedicada a definir actividades, el objetivo era rellenar la columna

de “Nombres de Tareas” y “Notas” en la herramienta Microsoft Project©. Se partió del
acta de constitución del proyecto, el enunciado del alcance, la EDT y el diccionario de
la EDT. En el acta de constitución y en el enunciado del alcance figuraban los
principales hitos. La estructura, codificación y nomenclatura de la EDT se utilizó para
estructurar de la misma forma los grupos de tareas (así se podría mantener la
trazabilidad entre actividades y paquetes de trabajo). Los paquetes de trabajo se
descompusieron a un mayor nivel de detalle hasta llegar a las tareas en las que debía
controlarse las fechas de inicio y fin. Un miembro del equipo de gestión se encargaba
de escribir los nombres de las tareas e hitos en Project y cuando se generaba
información de detalle sobre los atributos de las actividades, lo apuntaba en el campo
“Notas”.
4. En la reunión dedicada a secuenciar actividades, el equipo debatía sobre las

dependencias entre las tareas. Gráficamente se iba representando con las flechas del
Gantt, y también con la vista “Diagrama de Red”. Al equipo le interesaba sobre todo
distinguir si las relaciones lógicas eran duras o blandas, lo que quedó documentado en
el campo “Notas”.
5. A partir del organigrama del equipo y de la estructura de desglose de recursos,

que detallaba los tipos de recursos disponibles, aunque no sus nombres (ingenieros,
técnicos, etc.), el equipo de gestión fue capaz en la siguiente reunión de determinar los
recursos asociados a las actividades. En el campo “Nombres de Recursos” de la vista
Gantt de la herramienta Microsoft Project©, quedó anotada la carga prevista por
categoría de personal del equipo, así como otros recursos, de tipo material o por
servicios subcontratados. Por ejemplo, en una actividad en que se consumía un
ingeniero a media jornada, dos técnicos a dedicación completa, 20 noches de hotel, 5
billetes de avión y una subcontratación a precio cerrado por 10.000 €, la anotación en
el campo “Nombres de Recursos” quedó de la siguiente manera: ING [50%]; TEC
[200%]; HOTEL [20]; AVION [5]; SUBCO [10000€].
6. Sabiendo qué recursos tenían asignados las actividades, fue posible estimar
las duraciones de las actividades. Se involucró a expertos usando la técnica de
estimación por tres valores: En herramienta Microsoft Project©, para que el motor de
programación calculase el camino crítico, en el campo “Duración” se anotó la duración
más probable; sin embargo, a los interesados no se les comunicaban las duraciones
más probables, sino las duraciones estimadas y el margen de tiempo para tener una
confianza del 95%.
7. En la última reunión de planificación inicial se logró grabar la línea base del

cronograma. Al comienzo de la reunión no se cumplían las restricciones de tiempos,
recursos y costes: la programación en la herramienta indicaba ocho meses, no seis,
los ingenieros estaban infrautilizados unas semanas y debían hacer horas extra
durante otras; y tampoco se tenía en cuenta el límite de financiación (los costes
acumulados al tercer mes eran un 25% superiores a lo facturado, incumpliendo la
política de la empresa).

Por tanto, hubo que comprimir el cronograma aplicando adelantos, nivelando recursos,
solapando algunas actividades e intensificando algunas del camino crítico. A la hora
de solapar actividades (ejecución rápida) fue muy útil distinguir qué dependencias eran
duras (no se podían solapar) y cuáles eran dependencias blandas (las actividades sí
se podían solapar, asumiendo más riesgo).

a la derecha.
1 Requisitos de A Un calendario que identifica los días y turnos de trabajo en que cada recurso específico está
Recursos de las disponible.
Actividades
2 Duración B Actividad dependiente que lógicamente ocurre después de otra actividad en un cronograma.
3 Esfuerzo C Un punto en el tiempo asociado con la conclusión de una actividad del cronograma. Habitualmente es
calificada con una de las siguientes opciones: real, planificada, estimada, programada, temprana,
tardía, línea base, objetivo o actual.
4 Estimación D Una relación establecida con base en el conocimiento de las mejores prácticas dentro de un área de
aplicación particular o a un aspecto del proyecto donde se requiere una secuencia específica.
5 Fecha de E Grupo de actividades relacionadas en el cronograma, las cuales son agregadas y mostradas como una
Finalización única actividad.
6 Hito F Una evaluación cuantitativa del monto o resultado probable. Habitualmente se aplica a los costes,
recursos, esfuerzo y duraciones de los proyectos y normalmente va seguido de un modificador (p.ej.,
preliminar, conceptual, de factibilidad, de orden de magnitud, definitivo). Siempre debería incluir
alguna indicación de exactitud (p.ej., ± x por ciento).
7 Actividad G Una actividad que precede desde el punto de vista lógico a una actividad dependiente en un
Predecesora cronograma.
8 Lógica H Una representación gráfica de las relaciones lógicas que existen entre las actividades del cronograma
Preferencial / del proyecto.
Blanda / Suave
9 Diagrama de Red I Un punto o evento significativo dentro de un proyecto, programa o portafolio.
del Cronograma
del Proyecto
10 Calendario de J Los tipos y las cantidades de recursos requeridos para cada actividad en un paquete de trabajo.
Recursos
11 Pronósticos del K El total de períodos de trabajo (sin incluir vacaciones u otros períodos no laborales) requeridos para
Cronograma terminar una actividad del cronograma o un componente de la estructura de desglose del trabajo.
Generalmente, se expresa en jornadas o semanas laborales. A veces se equipara incorrectamente al
tiempo transcurrido.
12 Actividad L Estimaciones o predicciones de condiciones y eventos en el futuro del proyecto, basadas en la
Sucesora información y el conocimiento disponibles en el momento de calcular el cronograma.
13 Actividad M La cantidad de unidades laborales necesarias para terminar una actividad del cronograma o un
Resumen componente de la estructura de desglose del trabajo, generalmente expresado en horas, días o
semanas de trabajo.
Solución al Ejercicio 2: 1-J, 2-K, 3-M, 4-F, 5-C, 6-I, 7-G, 8-D, 9-H, 10-A, 11-L, 12-B,
13-E.


a la derecha.
1 Fecha de corte A Una relación entre las actividades del proyecto y aquéllas que no pertenecen al proyecto.
2 Dependencia B Un punto en el tiempo en el que se registra el estado del proyecto.
Discrecional
3 Dependencias C Una relación en la cual una actividad del cronograma tiene más de un predecesor.
Externas
4 Holgura total D La técnica de identificar fechas de inicio tempranas y tardías, así como fechas de finalización
tempranas y tardías, para las partes no completadas de actividades del cronograma del proyecto.
5 Lógica Dura E El conjunto de dependencias de actividades del cronograma que conforma un diagrama de red de
cronograma del proyecto.
6 Fecha Impuesta F La cantidad de tiempo en la que una actividad sucesora se deberá retrasar con respecto a una
actividad predecesora.
7 Retraso G Una fecha fija sobre una actividad del cronograma, habitualmente expresada como una fecha que
exige “comenzar después del” y “finalizar antes del”.
8 Adelanto H Proceso que consiste en evaluar escenarios a fin de predecir su efecto sobre los objetivos del
proyecto.
9 Dependencia I Una relación establecida con base en el conocimiento de las mejores prácticas dentro de un área de
Obligatoria aplicación particular o a un aspecto del proyecto donde se requiere una secuencia específica.
10 Red J Una representación gráfica de las relaciones lógicas que existen entre las actividades del cronograma
del proyecto.
11 Análisis de la Red K Una relación que es requerida por contrato o inherente a la naturaleza del trabajo.
12 Lógica de la Red L La cantidad de tiempo en la que una actividad sucesora se puede anticipar con respecto a una
actividad predecesora.
13 Convergencia de M Una relación que es requerida por contrato o inherente a la naturaleza del trabajo.
Caminos
14 Divergencia de N Una relación en la cual una actividad del cronograma tiene más de un sucesor.
Caminos
15 Análisis de O La cantidad de tiempo que una actividad del cronograma puede demorarse o extenderse respecto de
Escenarios “¿Qué su fecha de inicio temprana sin retrasar la fecha de finalización del proyecto ni violar ninguna
pasa si…?” restricción del cronograma.
Solución al Ejercicio 3: 1-B, 2-I, 3-A, 4-O, 5-K, 6-G, 7-F, 8-L, 9-M, 10-J, 11-D, 12-E,
13-C, 14-N, 15-H.


a la derecha.
1 Diagramas de Red A Una representación del plan para ejecutar las actividades del proyecto que incluye duraciones,
de las Actividades dependencias y demás información de planificación, utilizada para generar un cronograma del
proyecto junto con otros objetos de planificación.
2 Actividad en el B Una estimación o predicción de condiciones y eventos futuros para el proyecto, basada en la
Nodo (AON) información y el conocimiento disponibles en el momento de realizar el pronóstico. La información se
basa en el desempeño pasado del proyecto y en el desempeño previsto para el futuro, e incluye
información que podría ejercer un impacto sobre el proyecto en el futuro, tal como la estimación a la
conclusión y la estimación hasta la conclusión.
3 Ajuste de C Cualquier serie continúa de actividades del cronograma conectadas con relaciones lógicas en un
Adelantos y diagrama de red de cronograma del proyecto.
Retrasos
4 Colchón D Provisión de fondos en el plan para la dirección del proyecto para mitigar riesgos del cronograma y/o
costes. Se utiliza a menudo con un modificador (p.ej., reserva de gestión, reserva para contingencias)
con el objetivo de proporcionar más detalles sobre qué tipos de riesgos se pretende mitigar.
5 Pronóstico E Una técnica utilizada para encontrar formas de alinear las actividades atrasadas del proyecto con el
plan durante la ejecución del mismo.
6 Diagrama de F Una representación gráfica de las relaciones lógicas que existen entre las actividades del cronograma
Gantt del proyecto.
7 Actividad Sumaria G Una técnica utilizada para construir un modelo de programación en el cual las actividades se
representan mediante nodos y se vinculan gráficamente mediante una o más relaciones lógicas para
indicar la secuencia en que deben ser ejecutadas.
8 Cronograma H Un diagrama de barras con información del cronograma donde las actividades se enumeran en el eje
Maestro vertical, las fechas se muestran en el eje horizontal y las duraciones de las actividades se muestran
como barras horizontales colocadas según las fechas de inicio y finalización.
9 Actividad Casi I La cantidad de tiempo que una actividad del cronograma puede demorarse sin retrasar la fecha de
Crítica inicio temprana de ningún sucesor ni violar ninguna restricción del cronograma.
10 Camino de Red J La técnica de identificar fechas de inicio tempranas y tardías, así como fechas de finalización
tempranas y tardías, para las partes no completadas de actividades del cronograma del proyecto.
11 Holgura Libre K Una herramienta que proporciona nombres de componentes del cronograma, definiciones, relaciones
estructurales y formatos que sustentan la aplicación de un método de planificación.
12 Técnica de L Una técnica de estimación que aplica un promedio ponderado de estimaciones optimistas, pesimistas
Revisión y y más probables cuando hay incertidumbre en las estimaciones de las actividades individuales.
Evaluación de
Programas
13 Modelo de M Un cronograma del proyecto resumido que identifica los principales entregables, componentes de la
Programación estructura de desglose del trabajo y los hitos clave del cronograma.
14 Análisis de la Red N Una actividad del cronograma que tiene una holgura total baja. El concepto de casi crítico es aplicable
del Cronograma tanto a una actividad del cronograma como a un camino de red del cronograma. El límite inferior al
cual la holgura total se considera casi crítica está sujeto al juicio de expertos y varía de un proyecto a
otro.
15 Herramienta de O Grupo de actividades relacionadas en el cronograma, las cuales son agregadas y mostradas como una
Planificación única actividad.
Solución al Ejercicio 4: 1-F, 2-G, 3-E, 4-D, 5-B, 6-H, 7-O, 8-M, 9-N, 10-C, 11-I, 12-L,
13-A, 14-J, 15-K.


a la derecha.
1 Aplicación de A Representación gráfica de información relativa al cronograma. En el típico diagrama de barras, las
Adelantos y actividades del cronograma o los componentes de la estructura de desglose del trabajo se listan de
Retrasos arriba hacia abajo en el lado izquierdo del diagrama, los datos se presentan en la parte superior y la
duración de las actividades se muestra como barras horizontales ubicadas según fecha.
2 Diagrama de B Un calendario que identifica los días y turnos de trabajo disponibles para las actividades del
Barras cronograma.
3 Intensificación C Una técnica utilizada para acortar la duración del cronograma con el menor incremento de coste
mediante la suma de recursos.
4 Método de la D Un método aplicable al cronograma que permite al equipo del proyecto colocar colchones en
Cadena Crítica cualquier ruta del cronograma del proyecto para adaptarlo a los recursos limitados y a las
incertidumbres del proyecto.
5 Camino Crítico E Una técnica que se utiliza para ajustar la cantidad de tiempo entre actividades predecesoras y
sucesoras.
6 Ejecución rápida F Una técnica que se utiliza para ajustar las fechas de inicio y finalización de las actividades de modo
que el uso planificado de recursos sea igual o menor que la disponibilidad de recursos.
7 Método de G La secuencia de actividades que representa el camino más largo a través de un proyecto, lo cual
Diagramación por determina la menor duración posible.
Precedencia
(PDM)
8 Calendario del H Una técnica que ajusta las actividades de un modelo de programación de modo que la necesidad de
Proyecto recursos del proyecto no exceda ciertos límites predefinidos de recursos.
9 Cronograma del I Una técnica utilizada para construir un modelo de programación en el cual las actividades se
proyecto representan mediante nodos y se vinculan gráficamente mediante una o más relaciones lógicas para
indicar la secuencia en que deben ser ejecutadas.
10 Nivelación de J Una técnica de compresión del cronograma en la que actividades o fases que normalmente se
Recursos realizan en secuencia se llevan a cabo en paralelo por menos durante una parte de su duración.
11 Técnicas de K La cantidad de tiempo que una actividad del cronograma puede demorarse o extenderse respecto de
Optimización de su fecha de inicio temprana sin retrasar la fecha de finalización del proyecto ni violar ninguna
Recursos restricción del cronograma.
12 Equilibrio de L Técnicas utilizadas para acortar la duración del cronograma sin reducir el alcance del proyecto.
Recursos
13 Compresión del M Una salida de un modelo de programación que presenta actividades vinculadas con fechas
Cronograma planificadas, duraciones, hitos y recursos.
14 Holgura Total N Una técnica en la cual las fechas de inicio y finalización se ajustan en base a las restricciones de los
recursos con el objetivo de equilibrar la demanda de recursos con la oferta disponible.
Solución al Ejercicio 5: 1-E, 2-A, 3-C, 4-D, 5-G, 6-J, 7-I, 8-B, 9-M, 10-N, 11-F, 12-H,
13-L, 14-K.

Procesos del área de Gestión del Tiempo del Proyecto

Gestión del Tiempo del Proyecto tiene procesos en los grupos de planificación y
En el capítulo 6 de la Guía del PMBOK® se describen siete procesos para la

Gestión del Tiempo del Proyecto, que se definen así:
6.1 Planificar la Gestión del Cronograma: Establecer las políticas, los

procedimientos y la documentación necesarios para planificar, desarrollar, gestionar,
ejecutar y controlar el cronograma del proyecto.
6.2 Definir las Actividades: Identificar y documentar las acciones específicas

que se deben realizar para generar los entregables del proyecto.
6.3 Secuenciar las Actividades: Identificar y documentar las relaciones

existentes entre las actividades del proyecto.
6.4 Estimar los Recursos de las Actividades: Estimar el tipo y las cantidades de
materiales, recursos humanos, equipos o suministros requeridos para ejecutar cada
una de las actividades.
6.5 Estimar la Duración de las Actividades: Estimar la cantidad de periodos de

trabajo necesarios para finalizar las actividades individuales con los recursos
estimados.

6.6 Desarrollar el Cronograma: Analizar secuencias de actividades, duraciones,

requisitos de recursos y restricciones del cronograma para crear el modelo de
programación del proyecto.
6.7 Controlar el Cronograma: Dar seguimiento del estado de las actividades del
proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del
cronograma a fin de cumplir el plan. Para medir el cronograma se puede representar el
porcentaje completado de cada actividad, comparar las fechas de comienzo y fin
reales con las planificadas.

de Gestión del Tiempo del Proyecto:

Documentos del área de Gestión del Tiempo del Proyecto
A continuación se destacan los documentos relacionados con la Gestión del

Tiempo del Proyecto:

- WBS dictionary - Cost forecasts  Risk register
 Quality management plan - Schedule forecasts  Schedule data


Proyecto
 Plan de gestión de los requisitos - Pronósticos del cronograma  Datos del cronograma
 Plan de gestión del alcance  Enunciado del trabajo relativo a  Evaluaciones del desempeño del equipo
4.1. Planificar la Gestión del Cronograma
Planificar la Gestión del Cronograma es el proceso de establecer las políticas,

los procedimientos y la documentación necesarios para planificar, desarrollar,
gestionar, ejecutar y controlar el cronograma del proyecto. El beneficio clave de este
proceso es que proporciona orientación e indicaciones sobre cómo se gestionará el
cronograma del proyecto a lo largo del mismo.

El plan de gestión del cronograma es un componente del plan para la dirección

del proyecto. Documenta la forma en que se informará sobre las contingencias
relativas al cronograma y la forma en que se evaluarán las mismas. Es susceptible de
ser actualizado para reflejar cualquier cambio en la manera de gestionar el
cronograma.
4.1.1. ENTRADAS
 Plan para la dirección del proyecto:

 Línea base del alcance: incluye detalles del enunciado del alcance del
proyecto y de la EDT que se utilizan para definir las actividades, estimar la
duración y gestionar el cronograma.
 Otra información: p.ej., decisiones de costes, riesgos y comunicaciones.
 Acta de constitución del proyecto: define los hitos principales y los requisitos de
plazos que se identificaron en la fase de aprobación del proyecto.
 Factores Ambientales de la Empresa: Algunos factores que pueden influir en

este proceso:
 La disponibilidad de recursos y habilidades.
 El software de gestión de proyectos.
 Información comercial de dominio público, tal como información sobre
productividad de los recursos.

 Sistemas de autorización de trabajos de la organización.

en este proceso:
 Herramientas de monitorización e información.
 Información histórica.
 Herramientas de control del cronograma.
 Políticas, procedimientos y guías existentes, tanto formales como
informales.
 Plantillas.
 Guías para el cierre del proyecto.
 Procedimientos de control de riesgos, que incluyen categorías de riesgos,
definición de la probabilidad y del impacto, y la matriz de probabilidad e
impacto.
 Técnicas analíticas: Se pueden seleccionar opciones estratégicas sobre
metodología de planificación, herramientas y técnicas de planificación,
enfoques de estimación, formatos y software de gestión de proyectos.
 Reuniones: El equipo de dirección del proyecto puede celebrar reuniones de
planificación para desarrollar el plan de gestión del cronograma, invitando a
otros interesados como por ejemplo: el patrocinador del proyecto,
determinados miembros del equipo del proyecto, personas que ostenten
responsabilidades de planificación o ejecución del cronograma, etc.
4.1.3. SALIDAS
 Plan de gestión del cronograma: Establece los criterios y las actividades a

llevar a cabo para desarrollar, monitorizar y controlar el cronograma. Según las
necesidades del proyecto, el plan de gestión del cronograma puede ser formal
o informal, de carácter detallado o más general, e incluye los umbrales de
control adecuados. El contenido típico suele ser:
 Desarrollo del modelo de programación del proyecto: Se especifica la
metodología y la herramienta de planificación a utilizar.
 Nivel de exactitud: Se especifica el rango aceptable que se utilizará para
hacer estimaciones realistas sobre la duración de las actividades, que
puede contemplar una determinada holgura para contingencias.
 Unidades de medida: Se definen, para cada uno de los recursos, todas las
unidades que se utilizarán en las mediciones.

 Enlaces con los procedimientos de la organización: Por ejemplo, los

procesos para planificar el alcance deben ser coherentes con los procesos
para planificar el cronograma.
 Mantenimiento del modelo de programación del proyecto: Se define el
proceso que se utilizará para actualizar el estado y registrar el avance del
proyecto en el cronograma a lo largo del proyecto.
 Umbrales de control: Se pueden definir umbrales de variación para
monitorizar el desempeño del cronograma, que establezcan una variación
permitida, previamente acordada, antes de que sea necesario
desencadenar una acción. Los umbrales se expresan habitualmente como
un porcentaje de desviación con respecto a la línea base.
 Reglas para la medición del desempeño: Si se realiza la medición del
desempeño del cronograma mediante la gestión del valor ganado (EVM), el
plan de gestión del cronograma podría definir:
 Reglas para establecer el porcentaje completado.
 Hitos de control en que se medirán la gestión del avance y del
cronograma.
 Técnicas para medir el valor ganado (p.ej., líneas base, fórmula fija,
porcentaje completado, etc.)
 Medidas del desempeño del cronograma, tales como la variación del
cronograma (SV) y el índice de desempeño del cronograma (SPI).
 Formatos de los informes. Se definen los formatos y la frecuencia de
presentación de los diferentes informes relativos al cronograma
 Descripciones de los procesos. Se documentan las descripciones de cada
uno de los procesos de gestión del cronograma.
4.2. Definir las Actividades
Definir las Actividades es el proceso de identificar y documentar las acciones

específicas que se deben realizar para generar los entregables del proyecto. El
beneficio clave de este proceso es el desglose de los paquetes de trabajo en
actividades que proporcionan una base para la estimación, planificación, ejecución,
monitorización y control del trabajo del proyecto. En este proceso se encuentran
implícitas la definición y la planificación de las actividades del cronograma de modo
que se cumplan los objetivos del proyecto. El proceso de Crear la EDT identifica los
entregables del nivel más bajo de la estructura de desglose del trabajo, el paquete de
trabajo. Los paquetes de trabajo se descomponen normalmente en componentes más
pequeños denominados actividades, que representan el trabajo necesario para
completar los paquetes de trabajo.

4.2.1. ENTRADAS
 Plan de gestión del cronograma.

 Línea base del alcance: Describe la EDT, los entregables, las restricciones y
los supuestos del proyecto.
este proceso:
 Información comercial de dominio público almacenada en bases de datos
comerciales.
 Sistema de Información para la Dirección de Proyectos (PMIS).
en este proceso:
 La base de conocimiento de lecciones aprendidas, que contiene
información histórica relativa a las listas de actividades utilizadas en
proyectos anteriores de similares características
 Procesos estandarizados.
 Plantillas que contengan listas de actividades estándar o una parte de una
lista de actividades de un proyecto previo.
 Políticas, procedimientos y guías existentes relacionados con la
planificación de las actividades, ya sean formales o informales, tales como
la metodología de planificación.

 Descomposición: Se usa para dividir y subdividir el alcance del proyecto y los

entregables del mismo en partes más pequeñas y manejables. Las actividades
representan el esfuerzo necesario para completar un paquete de trabajo. Cada
paquete de trabajo se descompone en las actividades necesarias para producir
los entregables del paquete de trabajo. La participación de los miembros del
equipo en la descomposición puede contribuir a obtener resultados mejores y
más precisos.
 Planificación gradual: Es una técnica de planificación iterativa en la cual el
trabajo a realizar a corto plazo se planifica en detalle, mientras que el trabajo
futuro se planifica a un nivel más alto. Es una forma de elaboración progresiva.
 Juicio de expertos: Los miembros del equipo del proyecto u otros expertos con
experiencia y habilidad en planificación pueden aportar su experiencia a la hora
de definir las actividades.
4.2.3. SALIDAS
 Lista de actividades: Es una lista exhaustiva que abarca todas las actividades
del cronograma necesarias para el proyecto. Incluye, para cada actividad, un
identificador y una descripción. Cada actividad debería tener un título distintivo,
con una referencia a su ubicación dentro el cronograma.
 Atributos de las actividades: Amplían la descripción de las actividades, de
manera progresiva mientras se va teniendo información. He aquí algunos
atributos típicos:
 Identificador, nombre y descripción.
 Identificador de la EDT.
 Actividades predecesoras, sucesoras, relaciones lógicas, adelantos y
retrasos.
 Fechas impuestas.
 Requisitos de recursos.
 Restricciones y supuestos.
 Persona responsable de ejecutar el trabajo.
 Zona geográfica o lugar donde debe realizarse el trabajo.
 Calendario de proyecto.
 Nivel de esfuerzo, esfuerzo discreto y esfuerzo prorrateado.
 Lista de hitos: Un hito es un punto o evento significativo dentro del proyecto.
Una lista de hitos consiste en un listado en que se identifica todos los hitos y se
indica si éstos son obligatorios (como los exigidos por contrato), u opcionales.
Los hitos son similares a las actividades normales del cronograma, pero tienen
una duración nula, ya que representan un momento concreto en el tiempo.

4.3. Secuenciar las Actividades
Secuenciar las Actividades es el proceso que consiste en identificar y

documentar las relaciones entre las actividades del proyecto. El beneficio clave de
este proceso reside en la definición de la secuencia lógica de trabajo para obtener la
máxima eficiencia teniendo en cuenta todas las restricciones del proyecto.
4.3.1. ENTRADAS

 Lista de actividades: Los elementos que hay que secuenciar.
 Atributos de las actividades: Pueden describir una secuencia necesaria de
eventos o definir relaciones predecesoras o sucesoras.
 Lista de hitos: Puede incluir fechas programadas para hitos específicos.
 Enunciado del alcance del proyecto: Contiene la descripción del alcance del
producto, que incluye las características del producto que pueden afectar a la
secuenciación de las actividades. La secuenciación de las actividades también
puede verse afectada por otra información incluida en el enunciado del alcance
del proyecto, como entregables, restricciones y supuestos del proyecto.
este proceso:
 Las normativas gubernamentales o industriales.
 El sistema de información para la dirección de proyectos (PMIS).
 La herramienta de planificación.

 Los sistemas de autorización de trabajos de la organización.

en este proceso:
 Los archivos de proyecto provenientes de la base corporativa de
conocimiento.
 Políticas, procedimientos y guías, relacionadas con la planificación de
actividades.
 Plantillas que se puedan utilizar para agilizar la preparación de conjuntos de
actividades del proyecto.
 Método de Diagramación por Precedencia (Precedence Diagramming Method –

PDM-): Es una técnica utilizada para construir un modelo de programación en
el cual las actividades se representan mediante nodos y se vinculan
gráficamente mediante una o más relaciones lógicas para indicar la secuencia
en que deben ser ejecutadas. Esta forma de representar el diagrama de red de
un proyecto también se denomina actividad en nodo (Activity On Node –AON-).
No confundir con otro método de diagramación, caído en desuso, denominado
como método de diagramación por flechas (Arrow Diagramming Method –ADM-
), también conocido como actividad en flecha (Activity On Arrow –AOA-).
El método PDM incluye cuatro tipos de dependencias o relaciones lógicas.

 Finish-to-Start –FS- (Final a Inicio): El inicio de la actividad sucesora

depende de la finalización de la actividad predecesora. Es la relación
que se utiliza más a menudo.
 Finish-to-Finish –FF- (Final a Final): La finalización de la actividad
sucesora depende de la finalización de la actividad predecesora.
 Start-to-Start –SS- (Inicio a Inicio): El inicio de la actividad sucesora
depende del inicio de la actividad predecesora.
 Start-to-Finish –SF- (Inicio a Final): La finalización de la actividad
sucesora depende del inicio de la actividad predecesora.
 Determinación de dependencias: El equipo de dirección del proyecto distingue
cuatro tipos de dependencias al establecer la secuencia de las actividades:
 Dependencias obligatorias: Son aquéllas requeridas por contrato, o
inherentes a la naturaleza del trabajo. Las dependencias obligatorias a
menudo implican limitaciones físicas. A veces se utilizan las expresiones
“lógica dura” o “dependencia dura” para referirse a estas dependencias.
 Dependencias discrecionales: Se establecen con base en el conocimiento
de las mejores prácticas dentro de un área de aplicación determinada o a
algún aspecto poco común del proyecto, donde se desea una secuencia
específica, aunque existan otras secuencias aceptables. A veces, se
denominan “lógica preferida”, “lógica preferencial” o “lógica blanda”. Deben
documentarse totalmente, ya que pueden crear valores arbitrarios de
holgura total y pueden limitar las opciones posteriores de planificación.
Cuando se emplea la técnica de compresión de “ejecución rápida”, estas
dependencias discrecionales deben revisarse, y debe considerarse su
modificación o eliminación.
 Dependencias externas: Implican una relación entre las actividades del
proyecto y aquéllas que no pertenecen al proyecto. Normalmente, estas
dependencias están fuera del control del equipo del proyecto.
 Dependencias internas: Implican una relación de precedencia entre
actividades del proyecto y por regla general están bajo el control del equipo
del proyecto.
 Aplicación de adelantos (leads) y retrasos (lags): El equipo de dirección de
proyecto determina las dependencias que pueden necesitar un adelanto o un
retraso para definir con exactitud la relación lógica. No deben utilizarse
adelantos y retrasos para sustituir la lógica de la planificación. Deben
documentarse las actividades y sus supuestos relacionados.
 Un adelanto permite una aceleración de la actividad sucesora. Por ejemplo,
si la instalación eléctrica debe comenzar 2 horas antes que la fontanería, se
indicaría con una relación final-a-inicio con un adelanto de 2 horas.
 Un retraso ocasiona una demora en la actividad sucesora. Por ejemplo, si
en una obra civil, el vertido del hormigón debe finalizar, y luego esperar 4
días hasta que se seque, antes de levantar los muros, lo indicaríamos con
una relación final-a-inicio con un retraso de 4 días.

4.3.3. SALIDAS
 Diagramas de red del cronograma del proyecto: Un diagrama de red del

cronograma del proyecto es una representación gráfica de las relaciones
lógicas, también denominadas dependencias, entre las actividades del
cronograma del proyecto. Cualquier secuencia inusual de actividades en la red
debería describirse por escrito.
 Actualizaciones a los documentos del proyecto: Entre los documentos del
proyecto susceptibles de actualización se cuentan:
 Listas de actividades.
 Atributos de las actividades.
 Lista de Hitos.
 Registro de riesgos.

4.4. Estimar los Recursos de las Actividades
Estimar los Recursos de las Actividades tiene por objeto estimar tipo y
cantidades de materiales, personas, equipos o suministros requeridos para llevar a
cabo cada una de las actividades. El beneficio clave de este proceso es que identifica
tipo, cantidad y características de los recursos necesarios para completar la actividad,
lo que permite estimar el coste y la duración de manera más precisa. Está
estrechamente coordinado con el proceso 7.2 Estimar los Costes, pues el coste de
cada actividad dependerá de los recursos asignados.
4.4.1. ENTRADAS
 Plan de gestión del cronograma: Identifica el nivel de exactitud y las unidades

de medida a utilizar para la estimación de los recursos.
 Lista de actividades: Identifica las actividades que necesitarán recursos.
 Atributos de las actividades: Describen la información relevante de cada
actividad.
 Calendarios de recursos: Identifican los días y turnos de trabajo en que cada
recurso específico (como personas, equipos y material) estará disponible. Los
calendarios de recursos especifican cuándo y por cuánto tiempo estarán
disponibles los recursos identificados del proyecto durante la ejecución del
mismo. Esta información puede proporcionarse a nivel de actividad o a nivel de
proyecto.
 Registro de riesgos: Determinados eventos asociados al riesgo pueden influir
en la selección y disponibilidad de los recursos.

 Estimación de los costes de las actividades: El coste de un recurso puede

influir en su selección.
 Factores Ambientales de la Empresa: Por ejemplo, la localización y las
habilidades de los recursos.
en este proceso:
 Políticas y procedimientos relativos a los recursos humanos.
 Políticas y procedimientos relacionados con el alquiler y la adquisición de
suministros y equipos.
 Información histórica acerca de los tipos de recursos utilizados para
trabajos similares en proyectos anteriores.
 Juicio de expertos: Pueden recomendar qué recursos emplear en las

actividades.
 Análisis de alternativas: Tras un análisis de alternativas, se puede determinar
con mayor rigor quién debe realizar ciertas actividades, qué materiales hay que
emplear, qué alternativa es mejor y más rápida, si es mejor hacer o comprar,
etc.
 Datos publicados de estimaciones: Muchas empresas publican periódicamente
los índices de producción actualizados y los costes unitarios de los recursos
para una gran variedad de industrias, materiales y equipos, en diferentes
países y en diferentes ubicaciones geográficas.
 Estimación ascendente (bottom-up): Cuando el trabajo de una actividad no
puede estimarse con un grado razonable de confianza, se descompone a un
nivel mayor de detalle. Se estiman los recursos desglosados y luego se suman
para obtener los recursos de la actividad.
 Software de gestión de proyectos: El software de gestión de proyectos tiene la
capacidad de ayudar a planificar, organizar y gestionar los grupos de recursos,
y de desarrollar estimaciones sobre los mismos. En función de la complejidad
del software, pueden definirse las estructuras de desglose de recursos, su
disponibilidad y sus costes, así como diversos calendarios, para ayudar en la
optimización del uso de recursos.

4.4.3. SALIDAS
 Requisitos de recursos de las actividades: Se identifican los tipos y la cantidad

de recursos necesarios para cada actividad de un paquete de trabajo. La
documentación de los requisitos de recursos para cada actividad puede incluir
la base de la estimación de cada recurso, así como los supuestos
considerados al determinar los tipos de recursos que se aplican, su
disponibilidad y en qué cantidad se utilizan.
 Estructura de Desglose de Recursos: Representación jerárquica de los
recursos por categoría y tipo. Es útil para organizar y comunicar la información
sobre utilización de recursos.
proyecto que pueden actualizarse, se incluyen:
 Lista de actividades.
 Calendarios de recursos.
Ejercicio 6. En una actividad que dura dos años, se empleará un programador

sénior, dos programadores junior a dedicación completa y un analista al 30%. ¿Cuál
debe ser la dedicación del programador sénior si el coste total es de 300.960 € y la
tarifa media es de 30 €/h?
Solución:
 En primer lugar, hay que percatarse de que falta un dato: el número de horas
laborales al año. Esto es un Factor Ambiental de la Empresa, que el director de
proyectos debe conocer o preguntar. Supongamos que, según el convenio
laboral para este sector de actividad, se trabaja 1760 horas al año.
 En este ejercicio resulta cómodo trabajar con FTE (Full Time Equivalents –
FTE-) o equivalentes en personas a tiempo completo durante un plazo
determinado. FTE es una unidad de esfuerzo tan válida como personas-mes.

 En la tabla de abajo se puede comprobar que multiplicando las horas de

trabajo en 2 años por la carga de cada recurso en porcentaje (FTEs), se
obtiene el esfuerzo por perfil, en horas-persona. Nótese que los FTE, como
cualquier otra unidad de esfuerzo, se pueden sumar (de ahí que pueda usarse
la estimación ascendente): esta actividad emplea 2,85 FTEs, o 10.032 horas-
persona.
 La dedicación del programador sénior debe ser de un 55%, o bien 0,55 FTEs,
lo que puede calcularse iterando en la hoja de cálculo, o también directamente,
como se describe a continuación:
 La carga total de recursos para esta actividad es: 300960€ / 1760 h/año / 2
años / 30 €/h = 2,85 FTEs. Podemos restar la carga conocida del analista y
los programadores junior para obtener la carga del programador sénior:
2,85 – 0,3– 2 = 0,55 FTEs, o lo que es lo mismo, el programador senior
trabajará a un 55% de su capacidad.
4.5. Estimar la Duración de las Actividades
Estimar la Duración de las Actividades es el proceso de realizar una estimación

de la cantidad de períodos de trabajo necesarios para finalizar las actividades
individuales con los recursos estimados. El beneficio clave de este proceso es que
establece la cantidad de tiempo necesario para finalizar cada una de las actividades.

En este proceso se utiliza la información sobre el alcance del trabajo que

conlleva la actividad, los tipos de recursos necesarios, las cantidades estimadas de los
mismos y sus calendarios de utilización. En las estimaciones de las duraciones de las
actividades deben colaborar los especialistas, o las personas más familiarizadas con la
naturaleza del trabajo. La estimación de la duración se elabora de manera gradual, y el
proceso evalúa la calidad y disponibilidad de los datos de entrada.
Conviene distinguir los términos esfuerzo (effort), duración (duration) y tiempo

transcurrido (elapsed time). Como se puede apreciar en la figura, una actividad puede
requerir:
 Un esfuerzo de 25 días-persona, o 200 horas-persona (de 1 analista al 50% y 2

programadores al 100%).
 Una duración de 10 días.
 Un plazo de finalización de 15 días, incluyendo vacaciones y festivos.

4.5.1. ENTRADAS

 Lista de actividades.
 Atributos de la actividad.
 Requisitos de recursos de las actividades: La duración de las actividades
dependerá de los recursos requeridos. Por ejemplo: un recurso experimentado
puede tardar la mitad que otro sin experiencia, dos recursos asignados pueden
tardar la mitad que uno solo, etc.
 Calendarios de recursos: Ciertos perfiles pueden trabajar más o menos horas.
Ciertos recursos pueden no estar disponibles durante determinados periodos.
 Enunciado del alcance del proyecto: Contiene las restricciones y los supuestos.
 Registro de riesgos: Puede documentar incertidumbres que afecten a la
duración de ciertas actividades.
 Estructura de desglose de recursos: La tipología de los recursos pueden influir
en las duraciones. Por ejemplo, un recurso externo puede demorar una
actividad si hay que esperar hasta que se incorpore en el equipo.
 Factores Ambientales de la Empresa: Incluyen, entre otros:
 Bases de datos de los estimados de la duración y otros datos de referencia.
 Métricas de productividad.
 Información comercial publicada.
 Ubicación de los miembros del equipo.
 Activos de los Procesos de la Organización: Incluyen, entre otros:
 Información histórica relativa a la duración.
 Calendarios del proyecto.
 Metodología de planificación.
 Lecciones aprendidas.
 Estimación análoga: Consiste en usar las estimaciones de proyectos pasados
parecidos cuando son similares o no hay mucha información sobre el proyecto
actual. Es rápida y poco costesa, si bien puede no ser muy precisa. Por
ejemplo, podemos decir que estimamos que una actividad durará unos 20 días
ya que es análoga a otra actividad similar de un proyecto anterior comparable.
 Estimación paramétrica: La duración de la actividad puede determinarse
cuantitativamente a partir de ciertas variables del proyecto. Por ejemplo, para
una instalación de cable, si los recursos asignados son capaces de instalar 25
metros/hora, la duración para instalar 1.000 metros sería de unas 40 horas.

Con esta técnica pueden lograrse niveles más altos de exactitud, siempre y
cuando la información histórica sea precisa, los parámetros sean cuantificables
y el modelo sea escalable (para proyectos grandes y pequeños).
 Estimación por tres valores: Este método sirve para cuantificar el grado de
incertidumbre en las estimaciones. La duración esperada se aproxima a partir
de la media ponderada de 3 valores (optimista, más probable y pesimista). El
grado de confianza se expresa por medio de la desviación estándar: se dice
que hay un 68% de probabilidad de terminar en ±1σ, un 95% de probabilidad
de terminar en ±2σ y un 99% de probabilidad de terminar en ±3σ. Para calcular
rápidamente la desviación estándar, puede aproximarse con la fórmula σ =
(valor pesimista–valor optimista)/6. Por lo que respecta a la duración esperada,
se puede aproximar de dos maneras:
 Si se utiliza una distribución de probabilidad beta (se hace así en el método
PERT), entonces duración esperada = (pesimista + 4*más probable +
optimista) / 6.
En el ejemplo, la duración optimista para la actividad es de 20 días, la

pesimista de 35 días y la más probable es de 25 días. Utilizando la
distribución beta, podríamos decir que la duración estimada es entre 24 y
29 días con una confianza del 68%, o bien entre 21 y 31 días con una
confianza del 95%.
 Si por el contrario se utiliza una distribución de probabilidad triangular,

entonces duración esperada = (pesimista + más probable + optimista) / 3

En el mismo ejemplo, utilizando la distribución triangular, podríamos decir

que la duración estimada para es entre 24 y 29 días con una confianza del
68%, o bien entre 22 y 32 días con una confianza del 95%.
Ejercicio 7. Su equipo de gestión está planificando dos actividades

secuenciales A y B. A partir de la información que obtiene de los miembros de su
equipo, usando el método PERT, la estimación para actividad A es de 45±3 días
(confianza 65%) y para la actividad B es de 65±8 días (confianza 95%). Se decide
combinar las dos actividades en una sola. ¿Cuál es la estimación para la actividad
AB?
Solución:
 110 ± 10 días (confianza 95%):

 Duración esperada de AB = 45 + 65 = 110 días.
 Varianza de A = 3^2 = 9.
 Varianza de B = (8/2) ^2 = 16.
 Varianza de AB = 9+16 = 25 (varianza de la suma = suma de las
varianzas).
 Desviación estándar de AB = √25 = 5 días.
 Confianza 95% implica ± 2 σ = 5*2 = 10 días.

Ejercicio 8. La tabla muestra los tres valores para las actividades de un

proyecto. Se pide calcular la estimación para el proyecto completo.
Solución:
 Nótese que sólo se tienen en cuenta las actividades del camino crítico:
 El proyecto durará 1382 ± 85 días (confianza 68%)
 El proyecto durará entre 1296 y 1467 días (confianza 68%)
 Técnicas grupales de toma de decisiones: Los enfoques grupales, tales como
la tormenta de ideas o las técnicas Delphi o técnicas de grupo nominal, son
útiles para involucrar a los miembros del equipo en la mejora de la exactitud de
la estimación y del compromiso con las resultados de las estimaciones que se
produzcan.
 Análisis de Reservas: Las reservas son provisiones de fondos en el plan para
la dirección del proyecto para gestionar riesgos. Hay dos tipos de reservas. Las
reservas para contingencias forman parte de la línea base de costes: se
asignan a riesgos identificados que son aceptados y para los cuales se
desarrollan respuestas de contingencia (sirven para responder a los
imprevistos conocidos). La reserva de gestión no forma parte de la línea base
de coste: son fondos reservados para trabajos imprevistos dentro del alcance
del proyecto (sirven para responder a los imprevistos desconocidos).

Hay que tener en cuenta que responder a los imprevistos impacta no solo en
coste del proyecto, sino también en su duración. En la figura puede verse en
gris la línea base de coste de un proyecto (representando el presupuesto
mensual previsto). El incremento representado en color blanco representa la
reserva para contingencias. Como puede apreciarse, las reservas para
contingencias se pueden medir en coste y también en tiempo, y su efecto
podría llevarse al estimar las duraciones de las actividades.
4.5.3. SALIDAS
 Estimaciones de la duración de las actividades: Son valoraciones cuantitativas

de la cantidad probable de periodos de trabajo que se necesitarán para
completar una actividad. Recuerde que una estimación sin un ± no es una
estimación. Se recomienda utilizar rangos de fechas: En lugar de decir que el
proyecto durará exactamente 2 meses, es mejor decir que durará entre 6 y 10
semanas, por ejemplo.


 Supuestos adoptados.
4.6. Desarrollar el Cronograma
Desarrollar el Cronograma es el proceso de analizar secuencias de actividades,

duraciones, requisitos de recursos y restricciones del cronograma para crear el modelo
de programación del proyecto. El beneficio clave de este proceso es que al incorporar
actividades del cronograma, duraciones, recursos, disponibilidad de los recursos y
relaciones lógicas en la herramienta de planificación, ésta genera un modelo de
programación con fechas planificadas para completar las actividades del proyecto. A
medida que avanza el trabajo, la labor de revisión y mantenimiento del modelo de
programación para que sustente una planificación realista continúa y se mantiene todo
a lo largo del desarrollo del proyecto.
4.6.1. ENTRADAS
 Plan de gestión del cronograma: Identifica la metodología y la herramienta de

planificación a utilizar en el proyecto para el desarrollo del cronograma y la
manera en que se debe calcular el mismo.
 Lista de actividades: Identifica las actividades a incluir en el modelo de
programación.

 Atributos de las actividades: Proporcionan los detalles para la construcción del

modelo de programación.
 Diagramas de red del cronograma del proyecto: Contienen las relaciones
lógicas de precedentes y subsiguientes que se utilizarán para calcular el
cronograma.
 Requisitos de recursos de las actividades: Consisten en los tipos y las
cantidades de recursos identificados que necesita cada actividad y se utilizan
para generar el modelo de programación.
 Calendarios de recursos: Contienen información sobre la disponibilidad de los
recursos a lo largo del proyecto.
 Estimaciones de la duración de las actividades: Son valoraciones cuantitativas
de la cantidad probable de periodos de trabajo que se necesitarán para
completar una actividad que se utilizará para calcular el cronograma.
 Enunciado del alcance del proyecto: Contiene supuestos y restricciones que
pueden causar un impacto en el desarrollo del cronograma del proyecto.
 Registro de riesgos: Proporciona los detalles relativos a todos los riesgos
identificados que pueden afectar al modelo de programación y sus
características.
 Asignaciones de personal al proyecto: Especifican qué recursos se asignan a
cada una de las actividades.
 Estructura de desglose de recursos: Proporciona los detalles necesarios para
que se pueda realizar el análisis de los recursos y el informe organizativo.
 Factores Ambientales de la Empresa: Incluyen, entre otros:
 Estándares.
 Canales de comunicación.
 Herramienta de programación.
 Activos de los Procesos de la Organización: Incluyen, entre otros:
 Metodología de programación.
 Calendarios del proyecto.
 Análisis de la Red del Cronograma: Emplea diversas técnicas analíticas, tales

como el método de la ruta crítica, el método de la cadena crítica, el análisis
“Qué pasa si…” y la optimización de recursos para calcular las fechas de inicio
y finalización, tempranas y tardías, de las partes no completadas del proyecto.
Algunos caminos de la red pueden tener puntos de convergencia o divergencia
que se pueden identificar y emplear en el análisis de compresión del
cronograma o en otros tipos de análisis.
 Método del Camino Crítico: Esta técnica permite calcular el camino crítico del
cronograma, es decir, el camino más largo compuesto por actividades
dependientes, cuya duración coincide con la duración del proyecto. Se
denomina crítico porque cualquier retraso en una actividad del camino crítico, o
actividad crítica, produce el mismo retraso en el proyecto.

Un camino casi-crítico es aquel cuya duración es menor que la del camino

crítico, pero que si se retrasa alguna actividad puede llegar a convertirse en el
camino crítico.
El camino crítico puede calcularse manualmente en 3 pasos:
1) Dibujar el diagrama de red AON (Activity On Node), indicando la duración

de cada actividad (si se utiliza la estimación por tres valores, elegir la
estimación más probable).
A B C
7d 9d 2d
D E F G H
10d 5d 2d 4d 2d
I J
3d 4d
2) Calcular las fechas de inicio y finalización tempranas (Early Start, Early

Finish), mediante un recorrido hacia adelante, sumando las duraciones.
Después calcular las fechas de inicio y finalización tardías (Late Start, Late
Finish), mediante un recorrido hacia atrás, restando las duraciones.
3) Obtener el camino crítico, aquel que sus actividades tienen holgura cero. La
holgura total (total float o total slack) se calcula restando a inicio tardío el
inicio temprano, o bien restando la finalización tardía a la finalización
temprana. La holgura total de un camino es la suma de las holguras totales
de sus tareas. Por ejemplo, la holgura total de ABCGH es cero, mientras
que la holgura total de DEFGH es de 3 días.
1 7 8 16 17 18
A B C
1 7d 7 8 9d 16 17 2d 18
1 10 11 15 16 17 19 22 23 24
D E F G H
2 10d 11 12 5d 16 17 2d 18 19 4d 22 23 2d 24
11 13 14 17
I J
16 3d 18 19 4d 22
Se denomina holgura total (total float, total slack), al tiempo que una actividad
puede retrasar su inicio temprano, o su finalización tardía, sin retrasar la fecha de
término del proyecto. Se denomina holgura libre (free float, free slack), al tiempo que
una actividad puede retrasar su inicio temprano, o su finalización tardía, sin retrasar el
inicio temprano de cualquier actividad dependiente.

Si la holgura libre de una tarea es cero, esto no implica que sea crítica. En
cambio, si la holgura total de una tarea es cero, entonces es tarea crítica y su holgura
libre también es cero.
Si cualquier actividad del camino crítico se retrasa o dura más, el camino crítico
sigue siendo el mismo. Por otro lado, los caminos críticos fluctúan, es decir, un camino
crítico puede dejar de serlo por causa del adelanto o menor duración de alguna
actividad crítica, o por la mayor duración o retraso de alguna actividad en algún
camino casi crítico, etc. Además, hay que tener en cuenta que un cronograma puede
tener más de un camino crítico a la vez.
En la práctica, el camino crítico se calcula automáticamente usando

herramientas de planificación. Siguiendo con el ejemplo anterior, si se introducen los
datos de las actividades en Microsoft Project©, la herramienta puede calcular y
mostrar los valores ES, EF, LS, LF:
También puede calcular y mostrar los valores de las holguras libres y holguras
totales:
En la vista “Diagrama de Red” señala en color rojo el camino crítico:

Respecto a las holguras, puede comprobarse que la holgura libre de la

actividad I es nula (no puede retrasarse sin retrasar a su sucesora J), mientras que la
holgura libre de la actividad J es de 5 días. La actividad I es un ejemplo de que una
holgura libre nula no implica que la holgura total sea nula. Por último, toda actividad
crítica tiene holgura libre y holgura total nulas:
Ejercicio 9. Calcular el camino crítico y su duración en esta red PDM:
Solución: Dos caminos críticos de duración 13 días: CDE y CDF.

Ejercicio 10. Calcular el camino crítico y su duración en esta red PDM:
Solución: El camino crítico es CEHI de duración 20 días.
Ejercicio 11. Calcular el camino crítico y su duración en esta red PDM con
dependencias FF y SS:

Solución: El camino crítico es ABD. La duración del proyecto es 13 días
dependencia FF:
Solución: El camino crítico es CD. La duración del proyecto es 8 días.

dependencia SS con retraso:
Solución: El camino crítico es CE. La duración del proyecto es 14 días.

Ejercicio 14. Calcular el camino crítico y su duración en esta red ADM. ¿Qué
pasaría si la actividad AD se comprime un mes?
Solución: Para calcular el camino crítico hay que dibujar la red PDM:
Si utilizamos alguna herramienta de planificación como Microsoft Project,

también podremos representar el diagrama Gantt:

El camino crítico actual es: Inicio-B-A-D-Fin.
Si la actividad AD se comprime un mes, entonces hay dos caminos críticos: 1)

Inicio-B-A-D-Fin; 2) Inicio-B-E-Fin.
 Método de la Cadena Crítica: La gestión de proyectos por cadena crítica

(Critical Chain Project Management –CCPM-) fue introducida por el Dr. Eliyahu
M. Goldratt en 1977, en su famosa novela “Cadena Crítica”, en la que se
aplicaba la teoría de las restricciones (Theory Of Constrains –TOC-), también
ideada por el mismo autor, a la gestión de proyectos.

La tesis principal del libro es que “no se debe estimar con margen de
seguridad”. Esto conduce a la “dinámica de la sobre-estimación”. Las
estimaciones pesimistas se dan con una confianza del 95%, lo que puede
provocar un margen de seguridad del 150% (es decir, si la estimación más
probable –la que suele darse con una confianza del 50%- para un proyecto es
4 meses, se acaban proponiendo 6 meses).
Sin embargo, a pesar de que los proyectos se estiman con márgenes de

seguridad del 150%, se acaban retrasando por dos motivos, principalmente:
 La multi-tarea: Si un recurso dedica 10 jornadas para la tarea A, 10 para

B y 10 para C, cuando las hace en modo multi-tarea ABC-ABC, en
media, tarda el doble en finalizar.
 Los retrasos se traspasan enteros a las siguientes etapas, pero los

adelantos se pierden definitivamente. No hay motivación para informar
terminaciones tempranas. Aunque el margen de seguridad local no
haga falta, se gastará de todos modos, debido a:
 El síndrome del estudiante: Las actividades se comienzan poco
antes de su fecha límite.
 La ley de Parkinson: El trabajo se extiende hasta ocupar todo el
plazo planificado.

 El método de la cadena crítica se basa en los siguientes puntos:

 Cuantificar la incertidumbre de las duraciones haciendo explícitos los
buffers, compartiendo el conocimiento de los tamaños y la ubicación de los
buffers con los interesados. En las reuniones de seguimiento se actualizan
los buffers, mantener fecha de término. Hay 3 tipos de buffers:
 Buffer de Proyecto: Para proteger el camino crítico.
 Buffers de Alimentación: Para proteger los caminos que suelen acabar
convirtiéndose en críticos (los caminos casi-críticos).
 Buffers de Recursos: Los recursos críticos suelen definir la cadena

crítica (y también los buffers de alimentación). En la práctica, se protege
la cadena crítica avisando a los recursos críticos del comienzo
inminente de sus tareas.

 Técnicas de optimización de recursos: Permiten ajustar el modelo de

programación en función de la demanda y de la provisión de recursos:
 Nivelación de recursos (resource leveling): Es una técnica en la cual las
fechas de inicio y finalización se ajustan sobre la base de las restricciones
de los recursos, con el objetivo de equilibrar la demanda de recursos con la
oferta disponible. La nivelación de recursos se puede utilizar cuando los
recursos compartidos o críticos necesarios se encuentran únicamente
disponibles en determinados momentos o en cantidades limitadas, cuando
han sido sobrecargados, o cuando se desea mantener la utilización de
recursos en un nivel constante. La nivelación de recursos a menudo
provoca cambios en el camino crítico original, generalmente aumentando
su duración.
 Equilibrado de Recursos (resource smoothing): Es un tipo de nivelación que

consiste en ajustar las actividades para que las necesidades de recursos no
excedan ciertos límites predefinidos. Las actividades sólo se pueden
retrasar dentro del margen de su holgura libre y de la holgura total (el
camino crítico no cambia). Esta técnica es posible que no permita optimizar
totalmente los recursos, pero se mantiene la fecha de fin.
 Técnicas de modelado:
 Análisis de escenarios “Qué pasa si...”: Consiste en evaluar escenarios a fin

de predecir su efecto, positivo o negativo, sobre los objetivos del proyecto.
Los resultados pueden usarse para evaluar la viabilidad del cronograma del
proyecto bajo condiciones adversas, y para preparar planes de
contingencia y respuesta para superar o mitigar el impacto de situaciones
inesperadas. Por ejemplo, en la figura puede comprobarse que si las
actividades 2 y 3 tardasen 5 días más, pasarían a ser críticas y el proyecto
duraría 5 días más, mientras que si la actividad 4 terminase 8 días antes,
dejaría de ser crítica el proyecto terminaría 5 días antes.

 Simulación: La simulación implica calcular múltiples duraciones del

proyecto a partir de diferentes conjuntos de supuestos sobre las
actividades, generalmente mediante el uso de distribuciones de
probabilidades para tener en cuenta la incertidumbre. La técnica de
simulación más utilizada es el análisis de Monte Carlo.
Las herramientas de simulación permiten modelar la distribución de

probabilidades de cada actividad (típicamente introduciendo los tres valores
de duración más probable, pesimista y optimista, y eligiendo el tipo de
distribución: beta o triangular). Con estos datos, las herramientas son
capaces de simular miles de ocurrencias y representar una distribución de
probabilidades para el proyecto completo.
Por ejemplo: Si obtenemos esta curva después de simular 2000 resultados

con el análisis de Monte Carlo, podríamos decir que es imposible terminar
antes de marzo y es seguro terminar antes de junio; lo más probable es
terminar a finales de marzo, pero si queremos publicar una fecha de
finalización con una confianza mayor del 50%, la fecha de fin sería posterior
a mediados de abril.

 Adelantos y retrasos: Son refinamientos que se aplican al analizar de la red con

objeto de desarrollar un cronograma viable a través del ajuste del momento de
comienzo de las actividades sucesoras.
 Compresión del cronograma: En el ejemplo de la figura, un proyecto de dos
actividades en secuencia que duran 4 meses cada una, debe comprimirse de 8
meses a 6. Hay dos técnicas para reducir el plazo sin afectar al alcance o la
calidad:
 Intensificación (crashing): consiste en añadir recursos a las actividades (lo
cual supone mayor coste). A la hora de intensificar, deben analizarse
primero las actividades críticas que sea más barato acortar. En el ejemplo
se intensifican las dos actividades para reducir un mes cada una a costa de
asignar más recursos, lo que encarece el proyecto desde 200 k€ a 300 k€.
 Ejecución rápida (fast-tracking): consiste en paralelizar actividades que
normalmente deberían realizarse secuencialmente (lo cual introduce mayor
riesgo). Según se puede observar en el ejemplo, las actividades se solapan
durante 2 meses. No se aumenta el coste pero se aumenta el riesgo por
realizar en paralelo actividades que por buena práctica deberían ir en
secuencia.
 Herramienta de planificación: Aceleran el proceso de planificación mediante la
generación de fechas de inicio y finalización a partir de la información de
actividades, los diagramas de red, los recursos, las duraciones, etc. Se pueden
utilizar en combinación con otro software de gestión de proyectos, así como
con métodos manuales.
Ejercicio 15. Indicar qué actividades deberían intensificarse (y el coste

asociado) para reducir la duración del proyecto en 4 días:

Solución: Reducir la duración del proyecto de 13 hasta 9 días, intensificando 3

días la tarea C y 1 día la tarea D, por 170€:
 Los caminos críticos iniciales son CDE y CDF (ambos de 13 días)

 C es la más barata y alimenta los 2 caminos. Reducir C 3 días por un
coste de 120$
 Ahora CDE y CDF duran 10 días cada uno. Hay que reducir un día más
de cada camino
 D es ahora la tarea crítica más barata de intensificar. Reducirla 1 día
por 50$
 Coste total = 170$ (3 días de C, 1 día de D).
4.6.3. SALIDAS
 Línea base del Cronograma: Es la versión aprobada de un modelo de

programación que sólo se puede modificar a través de procedimientos formales
de control de cambios y que se utiliza como base de comparación con los
resultados reales. Se aprueba por los interesados adecuados como la línea
base del cronograma, con fechas de inicio y fin de línea base. Durante el
proceso de monitorización y control las fechas aprobadas de la línea base se
comparan con las fechas reales de inicio y fin para determinar si se han
producido desviaciones.
 Cronograma del Proyecto: Finalmente, como principal resultado del proceso
6.6 Desarrollar el Cronograma, se obtiene el cronograma del proyecto (project
schedule), que contiene las fechas planificadas para realizar las actividades y
para cumplir los hitos. Suele representarse de forma gráfica, con diagramas de
varios tipos:

 Diagramas de hitos: Representan solamente los hitos del proyecto.

Normalmente se utiliza este diagrama para mostrar la información relevante
a Dirección.
 Diagramas de barras: Las actividades se representan en forma de barras,
sin flechas de dependencia entre ellas, y mostrando solamente las
actividades resumen, para simplificar la representación. También se utiliza
este diagrama en las presentaciones a Dirección.
 Diagramas de red del cronograma del proyecto (o Diagrama de Gantt): La
forma más completa de representar el cronograma, se muestran barras y
flechas de dependencia.
 Datos del Cronograma: Es el conjunto de la información necesaria para

describir y controlar el cronograma. Entre los datos del cronograma del
proyecto se incluirán, como mínimo, los hitos del cronograma, las actividades
del cronograma, los atributos de las actividades y la documentación de los
supuestos y restricciones. Suelen incluir:
 Requisitos de recursos por periodo de tiempo, a menudo presentados en
formato de histograma de recursos.
 Cronogramas alternativos, tales como el mejor o el peor escenario, con o
sin nivelación de recursos, con o sin fechas obligatorias.
 Planificación de las reservas para contingencias.
 Histogramas de recursos.
 Proyecciones del flujo de caja.
 Cronogramas de pedidos y entregas.

 Calendarios del proyecto: Identifican los días y turnos de trabajo disponibles

para las actividades del cronograma. Distingue entre los periodos de tiempo, en
días o fracciones de días, disponibles para completar las actividades
planificadas y los periodos de tiempo no disponibles. Un cronograma podría
requerir más de un calendario del proyecto. Los calendarios del proyecto son
susceptibles de actualización.
 Actualizaciones al plan para la dirección del proyecto: Entre los elementos
susceptibles de actualización se cuentan:
 Línea base del cronograma.
 Plan de Gestión del Cronograma.
 Requisitos de recursos de las actividades: La nivelación de recursos puede
tener un efecto significativo en las estimaciones preliminares de los tipos y
cantidades de recursos necesarios.
 Atributos de las actividades: Se actualizan para incluir todos los requisitos
de recursos revisados y cualquier otra revisión realizada.
 Calendarios: Incluyendo los calendarios del proyecto y los calendarios de
los recursos.
 Registro de riesgos: Puede actualizarse para reflejar las oportunidades o
las amenazas identificadas al establecer los supuestos de la planificación.
5. Creación de la curva s y del presupuesto
La Gestión de los Costes del Proyecto incluye los procesos involucrados en

planificar, estimar, presupuestar, financiar, obtener financiamiento, gestionar, y
controlar los costes de modo que se complete el proyecto dentro del presupuesto
aprobado. En la gestión de costes del proyecto hay que tener en cuenta el efecto de
las decisiones tomadas en el proyecto sobre los costes recurrentes posteriores de
utilizar, mantener y dar soporte al producto, servicio o resultado del proyecto. Muchos
directores de proyecto ignoran los costes hasta que ya es demasiado tarde y el
proyecto se hace económicamente inviable. En todo proyecto, el director del proyecto
tiene la responsabilidad de conocer el desglose presupuestario, el margen previsto, el
presupuesto de cada cuenta de control a lo largo del tiempo, la financiación aprobada,
los hitos de facturación, etc. El objetivo de coste del proyecto es sin duda uno de los
más importantes en todos los proyectos de cualquier empresa. El director de proyectos
quiere saber cuánto cuesta su proyecto, pero no simplemente para satisfacer su
curiosidad, sino porque sabe que cuando su proyecto arroje pérdidas, él será el
máximo responsable.

En cada organización ejecutora hay unos factores ambientales y activos de

procesos que hay que dominar, especialmente en lo relativo a la gestión de costes:
¿Se usa EVM? Si no es así ¿cómo se miden las desviaciones y los pronósticos? Es
muy importante entender y hablar el lenguaje financiero con propiedad: Si su proyecto
tiene un WIP negativo, ¿eso es bueno o malo? Su jefe le dice que el DSO de su
proyecto es 20 días más de lo esperado ¿cómo se corrige? Aunque se trate de un
proyecto interno, un proyecto de voluntariado, o cualquier otro proyecto sin
contraprestación económica, es necesario estimar el esfuerzo y gestionar
proactivamente para no superarlo. En estos casos se suele utilizar “horas-persona”
como unidad de coste, o bien se traduce el esfuerzo a unidades monetarias
multiplicando las horas por la tarifa unitaria. Si no se conoce esta tarifa de coste, o es
un dato confidencial, suele emplearse una tarifa media de la categoría profesional
dentro de la empresa o dentro del sector de actividad.
Los pasos principales que debe seguir el equipo de dirección del proyecto para
gestionar los costes vienen descritos en el capítulo 7 de la Guía del PMBOK®:
 Planificar la Gestión de Costes: Como en cada plan secundario

correspondiente a un área de gestión, hay que dejar por escrito las reglas de
gestión que el equipo de dirección del proyecto se propone aplicar: ¿qué
unidades de medida se utilizarán? ¿qué moneda? ¿se controlarán todos los
tipos de coste o solo los costes directos por horas consumidas? ¿habrá
indicadores y umbrales para el seguimiento? ¿qué gastos podrá autorizar el
equipo de dirección del proyecto? ¿habrá reservas para imprevistos? ¿cómo se
aplicarán? etc., etc.
 Estimar los Costes: Teniendo en cuenta la información del cronograma, se
estima el coste de cada actividad (incluyendo un margen de incertidumbre:
recordar que sin un ± no es una estimación).
 Determinar el Presupuesto: Considerando los límites de financiación, las
reservas para contingencias y el tiempo, se determina la línea base de costes,
que representa gráficamente cuánto presupuesto se irá consumiendo por
periodo hasta alcanzar el presupuesto a la conclusión. Añadiendo las reservas
para imprevistos ya puede determinarse el presupuesto del proyecto (dato
esencial para la contabilidad de la organización).
 Controlar los Costes: Determinar desviaciones y pronósticos, analizar las
causas de los problemas y proponer, si es preciso, acciones correctoras o
preventivas.

Imaginemos un equipo de dirección del proyecto que gestiona eficazmente los

costes. ¿Qué actividades realizaría?
Ejercicio 2. Determinar el margen directo inicial y final de un proyecto. En el

plan para la dirección del proyecto figuraban estos datos:
 El proyecto durará 125 días. Se ha vendido al cliente por 1M€.

 En esta organización se reserva un 10% para imprevistos desconocidos.
 Se estiman unas reservas para contingencias de 50 k€.
 Serán necesarios 15 viajes a 5.000€ cada uno.
 Se ha de comprar un software por 12.000€ y un servidor hardware por 13.000€.
 El director del proyecto dedicará 1.000 horas al proyecto. Su tarifa de venta es
de 100 €/h.
 Trabajarán 5 empleados: 1.000 horas cada uno x 40 €/h (selling rate – tarifa
venta).
 Margen de venta: 25% sobre Standard Cost Rate (SCR – tarifa coste
estándar).
 Se subcontratará a 2 personas: 1.000 horas cada una x 50 €/h (selling rate –
tarifa venta).
 Se subcontratará un proyecto a precio cerrado por 250k€.
 El coste de la dirección repercutible a este proyecto es de 7.500€.
 El coste del departamento de ventas repercutible a este proyecto asciende a
12.500€.
 El coste por utilización de equipos, espacio y resto de instalaciones asciende a
10.000€.
A los 80 días del arranque, debido a ciertos cambios en el alcance, se tuvo que
replanificar el proyecto:
 El plazo del proyecto aumentó en 40 días.

 El presupuesto trasladado al cliente aumentó en 50k€, debido a la desviación
en los costes de las actividades a desarrollar por el equipo: se estimó un
aumento de 1.600 horas de recursos internos y una reducción en 280h de
recursos externos.
Finalmente, al cierre del proyecto:
 Se gastaron 20 viajes (en lugar de 15).

 Las reservas de gestión para imprevistos aplicadas fueron de 120k€ (en lugar
de 100k€). Las reservas para contingencias fueron aplicadas en su totalidad.
 Se ahorraron 320 horas en de recursos externos (sobre las 2000 planificadas
inicialmente).
 En cuanto a los recursos internos, se consumieron más horas de las
planificadas inicialmente (el director del proyecto 320 horas más y los
miembros del equipo 1.600 horas más).

Solución:
El margen directo de un proyecto es un término de contabilidad empresarial.

Como director de proyectos, usted debe conocer la terminología que utiliza el
departamento de contabilidad de su organización en lo relativo a la gestión de
proyectos. Si su organización vende proyectos a sus clientes, debe saber, entre otras
cosas, lo siguiente:
 Su proyecto será contabilizado como un ingreso por prestación de servicios en

el momento que pueda reconocerse parcial o totalmente el ingreso (principio
del devengo).
 Para su empresa es de la mayor importancia que su proyecto cumpla el plan
de facturación (usted lo llama “plan de financiación”). Usted es consciente de
que emitir una factura de 100k€ un mes tarde supone un coste financiero para
su empresa de unos 500€ como mínimo (a un interés bancario del 6%). O lo
que es lo mismo: el departamento comercial tendría que vender 10.000€ más
para compensar la pérdida (si el margen operativo con el que trabaja su
empresa es de un 5%).
 A partir de que el proyecto se aprueba (su cliente adjudica el servicio y firma un
contrato con su empresa), el departamento de contabilidad entiende que su
proyecto es una fuente de coste. Para ellos, básicamente hay dos tipos de
costes: las compras que su proyecto debe realizar para ejecutar el proyecto, y
los costes por la utilización o el consumo de recursos (horas de trabajadores y
otros costes de infraestructura). A su vez, estos costes de recursos pueden ser
costes directos (directamente ligados al servicio prestado) y costes indirectos
(no directamente relacionados con el proyecto, pero que hay que repartir por
contabilidad analítica a las distintas organizaciones ejecutoras –centros de
coste- y a su vez a los distintos proyectos como sub-centros de coste).
 La rentabilidad de su proyecto, también llamada beneficio, utilidad, o margen
comercial directo, o simplemente margen directo, se calcula en el momento de
la venta y finalmente se contrasta con el margen directo final.
 A este margen directo final se le restan los costes indirectos y queda el margen
operacional (de gran importancia para los análisis económicos). Al margen
comercial se le restan los gastos financieros y queda el beneficio antes de
impuestos. Como director del proyecto, su empresa le hará responsable del
objetivo de margen directo

 Como indicadores de progreso, para calcular las desviaciones y los pronósticos

en cada informe de situación, suele utilizarse el estándar EVM (Earned Value
Management).
Volviendo al caso planteado, como puede apreciarse en la figura, el margen

directo inicial es un 18%:
El presupuesto del proyecto es de 1.000k€.
 Los gastos ascienden a 350k€, resultado de sumar las compras en

infraestructura (13k€ en un servidor y 12k€ en licencias de software), la
subcontratación a precio cerrado por 250k€ y el presupuesto de viajes por
75k€.
 Los fondos de reservas ascienden a 150k€: 100k€ en reservas de gestión y
50k€ en reservas para contingencias.

 El presupuesto neto asciende a 500k€, resultado de restar al presupuesto bruto

los gastos y las reservas.
 En los costes directos se distinguen dos categorías: los costes por personal
subcontratado por horas ascienden a 100k€ = 50€/h*2.000h, y los costes de las
horas del personal interno. Teniendo en cuenta que la tarifa coste para el
director del proyecto es de 75€/h = 100€/h*(1-25%) y la tarifa coste para los
miembros del equipo es de 30€/h = 40€/h*(1-25%), queda un total para el coste
presupuestado para el personal interno de 225k€ =
75€/h*1.000h+30€/h*5.000h.
 Así pues, el margen directo inicial para este proyecto es de 175k€ (18% sobre
el presupuesto del proyecto).
 Si quisiéramos calcular el margen indirecto, habría que restar los costes
indirectos (30 k€) y obtendríamos un margen indirecto inicial del 15%.
En las empresas de consultoría, el margen directo previsto suele ser el factor

de mayor peso a la hora de decidir si merece la pena competir para ganar un proyecto,
ya que el esfuerzo comercial para realizar una propuesta puede llegar a ser muy
costoso (p. ej.: 3-4 personas de alto perfil a tiempo completo durante 20-30 jornadas).
Si usted es director de proyectos en una empresa de consultoría, debe

conocer el margen y gestionar su proyecto para conseguirlo. Tenga en cuenta que
muy probablemente será el principal indicador de desempeño financiero por el que le
evalúen dentro de su organización.
Finalmente, tal y como salieron las cosas, el margen directo final fue de un
12%:
 El presupuesto del proyecto ascendió a 1.050k€ después de la ampliación por

50k€.
 Los gastos ascendieron a 375k€, pues se gastaron 25k€ más en viajes (5
viajes * 5.000€ cada uno).

 Los fondos de reservas empleados ascendieron a 170k€: 120k€ por

imprevistos y 50k€ por contingencias.
 El presupuesto neto fue de 505k€, resultado de restar al presupuesto bruto los
gastos y las reservas.
 Los costes directos por personal subcontratado por horas fueron de 84k€. Es
decir: 100k€ menos los 16k€ que ahorrados en horas de T&M (320h * 50€/h).
 Los costes directos por personal interno fueron 297k€. El director del proyecto
incurrió 1.320h*75€/h=99k€. Los miembros del equipo incurrieron
6.600h*30€/h=198k€.
 Así pues, el margen directo final este proyecto es de 124k€ (12% sobre el
presupuesto del proyecto).
Contrastando las gráficas inicial y final, la alta dirección puede observar el

resultado financiero del proyecto:
La lectura financiera del proyecto se completa con el plan de facturación y la

facturación final:

Puede observarse que no se pudo emitir la factura inicial prevista de 50k€

(¿hubo problemas a la hora de formalizar el contrato?). Tampoco se pudo facturar los
meses 3 y 5 como estaba previsto (¿incumplimiento de los correspondientes hitos?).
Como el proyecto se extendió, tampoco se consiguió facturar la totalidad hasta el mes
8.
Ejercicio 3. Sobre el mismo caso práctico del ejercicio anterior: Desarrollar la

línea base de costes, una simulación del desempeño de costes transcurridos 80 días y
el informe final de cierre de la gestión de costes.
Solución:
 Como resultado del proceso 7.1 Planificar la Gestión de Costes se generó el

plan de gestión de costes. Se decidió que se controlarían los costes a nivel de
cuenta de control con EVM, excluyendo reservas para imprevistos, utilizando la
tarifa de venta de los recursos internos (no la tarifa de coste). Se monitorizan
los costes en euros, considerando los gastos y el consumo de los recursos.
 Supongamos que en la línea base del alcance y el cronograma se identificaron

tres cuentas de control. Como resultado del proceso 7.2 Estimar los Costes se
estimó el presupuesto esperado de cada una de ellas. Supongamos que la
cuenta de control 000. Gestión tiene un presupuesto de 125k€, resultado de
sumar 25k€ en compras y 100k€ por las horas del director del proyecto (1.000h
* 100€/h). La cuenta 100. Trabajos Equipo tiene un presupuesto de 375k€: 15
viajes * 5.000€ + 5.000h * 40€/h por recursos internos + 2.000h * 50€/h por
recursos subcontratados. Los trabajos subcontratados a precio cerrado se
controlan en la cuenta de control 200. Trabajos Externalizados (presupuesto
250k€). Como puede comprobarse, el presupuesto a la conclusión (Budget At
Completion –BAC) asciende a 750k€. Este será el objetivo de coste para medir
desviaciones y pronósticos.

 Como resultado del proceso 7.3 Determinar el Presupuesto se generó la línea

base de costes de la figura:
Situémonos ahora en la reunión de seguimiento transcurridos 80 días desde el

arranque del proyecto. Los datos de desempeño del trabajo nos ofrecen la siguiente
información de alcance y cronograma:
 Los trabajos de las cuentas de control 000 y 100 muestran un grado de avance
del 50%. Los trabajos externalizados aún no han comenzado. En
consecuencia, el proyecto se ha completado al 33%.
 Los trabajos de las cuentas de control 000 y 100 han comenzado cuando se
esperaba y parece ser que terminarán en la fecha prevista. Los trabajos de la
cuenta de control 200 aún no han comenzado pero se espera que terminen la
fecha prevista.
 Sin embargo, los datos de facturación y desempeño de costes (Valor
Planificado=469k€, Coste Real=348k€ y Valor Ganado=250k€), nos hacen
presagiar que el desempeño hasta la fecha no es aceptable.

Veamos a continuación la tabla con los datos del valor ganado:
 El índice de desempeño de costes (CPI=0,72) indica que por cada € invertido

en el proyecto estamos produciendo por valor de 72 céntimos. Pero según el
índice de desempeño del trabajo por completar (TCPI=1,24), cada euro
invertido debería producir 1,24€ para terminar en presupuesto. Actualmente
tenemos un sobrecoste de 98k€ y si seguimos así habrá una desviación final
de 294k€ (la estimación a la conclusión es de 1.044k€).
 El índice de desempeño del cronograma (SPI=0,58) dice que vamos
avanzando a una velocidad del 58% sobre la que deberíamos tener. Por el
indicador SV (t) sabemos que vamos retrasados 34 días.
 Por lo que se refiere a la facturación (véase la gráfica), tampoco vamos bien: A

la fecha deberíamos haber facturado 550k€ pero solo hemos facturado 150k€.
Comparando con lo producido (EV=250k€) tenemos un WIP (en curso sin
facturar) de 100k€. Es decir, según el indicador DSO (Days Sales Outstanding)
estamos financiando al cliente por 32 días.

Para involucrar a los directores ejecutivos, es recomendable representar la

información en las siguientes gráficas:
El análisis de las causas de las variaciones permitió descubrir que el cliente

estaba solicitando más requisitos y por otro lado no iba aceptando las entregas.
Siguiendo el procedimiento de escalado se solicitó una reunión entre el patrocinador y
el cliente que tuvo como resultado aumentar el alcance (y consecuentemente el
presupuesto y el plazo). Estos cambios impactaron de la siguiente forma:
 El presupuesto del proyecto aumentó desde 1.000k€ hasta 1.050k€. El

presupuesto a la conclusión (BAC) aumentó desde 750k€ hasta 800k€. La
línea base de costes se modificó para reflejar el aumento del presupuesto. La
gráfica EVM quedó de la siguiente forma:

 El presupuesto de la cuenta de control 100 aumentó desde 375k€ hasta 425k€:
 Las cuentas de control 000, 100 y 200 retrasan 40 días su fecha estimada de
finalización:
Veamos ahora cómo queda la información de desempeño en el informe de

cierre del proyecto:
 Todos los entregables han sido aceptados, el proyecto está completado al

100% y se ha terminado la fecha prevista:

 Todas las facturas se han emitido (la última el día de cierre formal):
 Finalmente, las gráficas del valor ganado muestran cómo se terminó con un
sobrecoste de 55k€, que sin duda es alto, pero no tanto como el sobrecoste
acumulado a mitad del proyecto de 294k€. De hecho, las gráficas muestran
cómo la tendencia mejoró con la replanificación:


a la derecha.
1 Estimación de los A Presupuesto dentro de la línea base de coste o línea base para la medición del desempeño que se
Costes de las asigna a riesgos identificados que son aceptados y para los cuales se desarrollan respuestas de
Actividades contingencia o mitigación.
2 Coste Real B La estimación aprobada para el proyecto o cualquier componente de la estructura de desglose del
trabajo o actividad del cronograma.
3 Estimación C La suma de todos los presupuestos establecidos para el trabajo a ser realizado.
Análoga
4 Esfuerzo D El monto del déficit o superávit presupuestario en un momento dado, expresado como la diferencia
Prorrateado entre el valor ganado y el coste real.
5 Base de las E Documentación de apoyo que describe los detalles utilizados para establecer estimaciones del
Estimaciones proyecto tales como supuestos, restricciones, nivel de detalle, rangos y niveles de confianza.
6 Estimación F Un método de estimación de la duración o el coste del proyecto mediante la suma de las estimaciones
Ascendente de los componentes de nivel inferior en la estructura de desglose del trabajo (EDT).
7 Presupuesto G La cantidad de trabajo ejecutado a la fecha, expresado en términos del presupuesto autorizado para
ese trabajo.
8 Presupuesto hasta H Una técnica para estimar la duración o el coste de una actividad o un proyecto utilizando datos
la Conclusión históricos de una actividad o proyecto similar.
9 Reserva para I Una actividad en la que el esfuerzo se reparte proporcionalmente a través de ciertos esfuerzos
Contingencias discretos y que no es divisible en esfuerzos discretos.
10 Índice de J Una medida de eficiencia en función de los costes de los recursos presupuestados expresada como la
Desempeño del razón entre el valor ganado y el coste real.
Coste
11 Desviación del K El coste total previsto de completar todo el trabajo, expresado como la suma del coste real a la fecha
Coste y la estimación hasta la conclusión.
12 Esfuerzo Discreto L Una actividad que puede planificarse y medirse y que produce una salida específica.
13 Valor Ganado M El coste real incurrido por el trabajo llevado a cabo en una actividad durante un período de tiempo
específico.
14 Gestión del Valor N El coste proyectado de la actividad planificada que incluye el coste de todos los recursos requeridos
Ganado para ejecutar y completar la actividad, incluidos todos los tipos y componentes de costes.
15 Estimación a la O Una metodología que combina medidas de alcance, cronograma y recursos para evaluar el
Conclusión desempeño y el avance del proyecto.
Solución al Ejercicio 4: 1-N, 2-M, 3-H, 4-I, 5-E, 6-F, 7-B, 8-C, 9-A, 10-J, 11-D,
12-L, 13-G, 14-O, 15-K.


a la derecha.
1 Estimación Hasta A El coste previsto para terminar todo el trabajo restante del proyecto.
la Conclusión
2 Método de la B Pronóstico de los costes del proyecto a ser pagados que se derivan de la línea base de coste para los
Fórmula Fija requisitos totales o periódicos, incluidos los gastos proyectados más las deudas anticipadas.
3 Conciliación del C Medida del desempeño del coste que se debe alcanzar con los recursos restantes a fin de cumplir con
Límite de un objetivo de gestión especificado. Se expresa como la tasa entre el coste para culminar el trabajo
Financiamiento pendiente y el presupuesto restante.
4 Nivel de Esfuerzo D Una técnica de estimación en la que se utiliza un algoritmo para calcular el coste o la duración con
base en datos históricos y parámetros del proyecto.
5 Reserva de E Un monto del presupuesto del proyecto retenido para fines de control de gestión. Estos son
Gestión presupuestos reservados para trabajo imprevisto que está dentro del alcance del proyecto. No está
incluida en la línea base para la medición del desempeño (PMB).
6 Estimación F El presupuesto autorizado que ha sido asignado al trabajo planificado.
Paramétrica
7 Valor Planificado G Un método del valor ganado para asignar un porcentaje especificado del valor presupuestado de un
paquete de trabajo al hito inicial del mismo, donde el porcentaje restante del valor presupuestado se
asigna una vez concluido el paquete de trabajo.
8 Requisitos de H Enfoque utilizado para optimizar los costes del ciclo de vida del proyecto, ahorrar tiempo, aumentar
Financiamiento las ganancias, mejorar la calidad, ampliar la participación en el mercado, resolver incidentes, y/o
del Proyecto utilizar recursos de forma más efectiva.
9 Índice de I Una actividad que no produce productos finales definitivos y que se mide con el paso del tiempo.
Desempeño del
Cronograma
10 Desviación del J Técnica utilizada para estimar el coste o la duración mediante la aplicación de un promedio de
Cronograma estimaciones optimistas, pesimistas y más probables, generalmente usado cuando existe
incertidumbre con las estimaciones de las actividades individuales.
11 Estimación por K Una medida de eficiencia del cronograma que se expresa como la razón entre el valor ganado y el
Tres Valores valor planificado.
12 Índice de L Una medida de desempeño del cronograma que se expresa como la diferencia entre el valor ganado y
Desempeño del el valor planificado.
Trabajo por
Completar
13 Ingeniería del M Un método del valor ganado que divide un paquete de trabajo en segmentos medibles, donde cada
Valor uno culmina con un hito fácilmente identificable observable, y luego asigna un valor ponderado al
cumplimiento de cada hito.
14 Desviación a la N Proyección del monto del déficit o superávit presupuestario, expresada como la diferencia entre el
Conclusión presupuesto al concluir y estimación al concluir.
15 Método de Hitos O El proceso de comparar el gasto planificado de fondos del proyecto con cualquier límite sobre el
Ponderados desembolso de fondos para el proyecto a fin de identificar cualquier desviación entre los límites de
financiamiento y los gastos planificados.
Solución al Ejercicio 5: 1-A, 2-G, 3-O, 4-I, 5-E, 6-D, 7-F, 8-B, 9-K, 10-L, 11-J,
12-C, 13-H, 14-N, 15-M.

Procesos del área de Gestión de los Costes del Proyecto

Gestión de los Costes del Proyecto tiene procesos en los grupos de planificación y
control:
En el capítulo 7 de la Guía del PMBOK® se describen cuatro procesos para la

Gestión de los Costes del Proyecto, que se definen así:
7.1 Planificar la Gestión de Costes: Establecer las políticas, los procedimientos y la

documentación necesarios para planificar, gestionar, ejecutar el gasto y controlar los
costes del proyecto.
7.2 Estimar los Costes: Desarrollar una aproximación de los recursos financieros
necesarios para completar las actividades del proyecto.
7.3 Determinar el Presupuesto: Sumar los costes estimados de las actividades

individuales o de los paquetes de trabajo para establecer una línea base de coste
autorizada.
7.4 Controlar los Costes: Monitorizar el estado del proyecto para actualizar los costes
del mismo y gestionar posibles cambios a la línea base de costes.


de Gestión de los Costes del Proyecto:

Documentos del área de Gestión de los Costes del Proyecto

Costes del Proyecto:


Proyecto

5.1. Planificar la Gestión de Costes
Planificar la Gestión de Costes es el proceso que establece las políticas, los

procedimientos y la documentación necesarios para planificar, gestionar, ejecutar el
gasto y controlar los costes del proyecto. El beneficio clave de este proceso es que
proporciona orientación e indicaciones sobre cómo se gestionarán los costes del
proyecto a lo largo del mismo.
El plan de gestión de costes es un componente del plan para la dirección del

proyecto. Documenta los procesos de gestión de costes, así como sus herramientas y
técnicas asociadas.
5.1.1. ENTRADAS
 Plan para la dirección del proyecto:

 Línea base del alcance: incluye detalles del enunciado del alcance del
proyecto y de la EDT que se utilizan para definir las actividades, estimar la
duración y gestionar el cronograma.
 Línea base del cronograma: específica en qué momento se incurrirán los
costes del proyecto.
 Otra información: p.ej., decisiones de costes, riesgos y comunicaciones.

 Acta de constitución del proyecto: define los requisitos para la aprobación del
proyecto, que influirán en la gestión de los costes del mismo.
este proceso:
 Las condiciones del mercado para comprar productos y servicios,
proveedores etc.
 Las tasas de cambio de divisas, para los proyectos cuyos costes se
originan en más de un país.
 Información comercial de dominio público, tales como tarifas publicadas de
recursos humanos, materiales y equipos y listas de precios publicadas por
los proveedores.
 El software de gestión de proyectos.
en este proceso:
 Procedimientos de control financiero (p.ej., informes de tiempos, revisiones
requeridas de gastos y desembolsos, códigos contables y disposiciones
contractuales estándar).
 Información histórica y bases del conocimiento de lecciones aprendidas.
 Bases de datos financieras.
 Políticas, procedimientos y guías existentes, formales e informales,
relacionados con la gestión de costes y el presupuesto.
 Técnicas analíticas: Se pueden seleccionar opciones estratégicas para
financiar el proyecto (p.ej., auto-financiación, endeudamiento, ampliación de
capital), para adquirir los recursos del proyecto (p.ej., desarrollo a medida,
compra, alquiler o leasing), etc.
planificación para desarrollar el plan de gestión de costes, invitando a otros
interesados como por ejemplo: el patrocinador del proyecto, determinados
miembros del equipo del proyecto, personas que ostenten responsabilidades
relativas a los costes del proyecto, etc.

5.1.3. SALIDAS
 Plan de gestión de costes: Describe la forma en que se planificarán,

estructurarán y controlarán los costes del proyecto. Documenta los procesos de
gestión de costes, así como sus herramientas y técnicas asociadas. El
contenido típico suele ser:
 Unidades de medida: Se definen, para cada uno de los recursos, todas las
unidades que se utilizarán en las mediciones.
 Nivel de precisión: Consiste en el grado de redondeo, hacia arriba o hacia
abajo, que se aplicará a las estimaciones de coste de las actividades.
 Nivel de exactitud: Se especifica el rango aceptable (p.ej., ±10%) que se
utilizará para hacer estimaciones realistas sobre el coste de las actividades,
que puede contemplar una holgura para contingencias.
 Enlaces con los procedimientos de la organización: La estructura de
desglose del trabajo (EDT) establece el marco general para el plan de
gestión de costes y permite que haya coherencia con las estimaciones, los
presupuestos y el control de los costes. El componente de la EDT que se
utiliza para la contabilidad de los costes del proyecto se denomina cuenta
de control. A cada cuenta de control se le asigna un código único, o
números de cuenta vinculados directamente con el sistema de contabilidad
de la organización ejecutora.
 Umbrales de control: Se pueden definir umbrales de desviación para
monitorizar el desempeño de los costes, que establezcan una desviación
permitida, previamente acordada, antes de que sea necesario
desencadenar una acción. Los umbrales se expresan habitualmente como
un porcentaje de desviación con respecto a la línea base.
 Reglas para la medición del desempeño: Si se realiza la medición del
desempeño de costes mediante la gestión del valor ganado (EVM), el plan
de gestión de costes podría definir: Los hitos en los que se realizará la
medición de las cuentas de control; los métodos de medición del valor
ganado y las metodologías de seguimiento y las fórmulas de cómputo de
gestión del valor ganado.
 Formatos de los informes: formatos y la frecuencia de presentación de los
diferentes informes de costes.
 Descripciones de los procesos: descripciones de cada uno de los procesos
de gestión de los costes.
 Detalles adicionales: Estratégica de financiación, procedimientos a seguir
ante fluctuaciones en los tipos de cambio, procedimientos de registro de la
información de costes, etc.
 En cuanto a los métodos de medición del valor ganado, para los paquetes
de trabajo que suponen esfuerzo discreto (panificables, medibles y con
resultados específicos), se podría elegir entre los siguientes cuatro métodos
de medición:

 Porcentaje completado: Se estima el grado de avance sobre 100%.

 Hitos ponderados: Se divide el paquete de trabajo en segmentos
medibles que terminan en hitos observables, a los cuales se le asigna
un peso relativo sobre 100%.
 Fórmula fija: Se gana un porcentaje del presupuesto cuando comienza
el esfuerzo, y el resto a la finalización. Típicamente se usan los métodos
50/50, 25/75 ó 0/100.
 Avance físico: Se usan unidades que pueden relacionarse
explícitamente con el grado de avance del trabajo (metros de cable
desplegado, superficie de hormigón vertida, etc.)
Ejercicio 6. La medición realizada sobre una cuenta de control con 4 paquetes

de trabajo A, B, C y D muestra los siguientes valores. Calcule EV de la cuenta de
control usando use porcentaje completado, fórmula fija 0/100, 25/75, y 50/50.
Solución:
 EV usando porcentaje completado: es 100%*100+80%*100+30%*100+0%*100

= 100+80+30+0 = 210€
 EV usando fórmula fija 0/100: 100%*100+0%*100+0%*100+0%*100 =
100+0+0+0 = 100€
100+25+25+0 = 150€
100+50+50+0 = 200€
5.2. Estimar los Costes
Estimar los Costes es el proceso de desarrollar una aproximación de los

recursos financieros necesarios para completar las actividades del proyecto. El
beneficio clave de este proceso la determinación de los costes requeridos para
completar las actividades del proyecto.

En este proceso se estiman los costes de los recursos necesarios para

completar las actividades del proyecto. Estos incluyen: costes de personal, materiales,
equipamiento, servicios e instalaciones y otras categorías especiales: factor de
inflación, costes de financiación, reservas para contingencias, etc. Las estimaciones
de costes se expresan normalmente en unidades de alguna moneda (p.ej., dólares,
euros, yenes, etc.), aunque en algunos casos pueden emplearse otras unidades de
medida, como las horas o los días de trabajo del personal para facilitar las
comparaciones o bien para eliminar el efecto de las fluctuaciones de las divisas.
Las estimaciones de los costes de las actividades se deben revisar y refinar a

lo largo del transcurso del proyecto para ir reflejando los detalles adicionales a medida
que éstos se van conociendo y que se van probando los supuestos de partida. La
exactitud de la estimación del coste de un proyecto aumenta conforme el proyecto
avanza a través de su ciclo de vida. Un proyecto en su fase de inicio, por ejemplo,
puede tener una estimación aproximada de orden de magnitud (ROM) en el rango de
−25% a +75%. Conforme se va contando con más información, el rango de exactitud
de las estimaciones puede reducirse a ±10%.

5.2.1. ENTRADAS
 Plan de gestión de costes.

 Planificación de los Recursos Humanos: Qué tipos dotación de personal
requieren las actividades, tarifas, salarios, compensaciones/reconocimientos,
etc.
 Línea Base del Alcance: La línea base del alcance puede contener información
adicional con implicaciones contractuales y legales, tales como las
relacionadas con la salud, la seguridad, el desempeño, el medioambiente, los
seguros, los derechos de propiedad intelectual, las licencias y los permisos. Se
debe tener en cuenta toda esta información a la hora de elaborar las
estimaciones de costes. Por otra parte, cada uno de los tres componentes de la
línea base del alcance pueden contener información específica necesaria para
estimar los costes de las actividades:
 En el enunciado del alcance del proyecto se detallan los supuestos y las
restricciones. Uno de los supuestos básicos que es necesario establecer
cuando se estiman los costes de un proyecto es si las estimaciones se
limitarán únicamente a los costes directos del proyecto o si incluirán
además los costes indirectos. Los costes indirectos son aquéllos que no se
pueden asignar de manera directa a un único proyecto específico y que, por
lo tanto, se acumularán y distribuirán equitativamente entre varios
proyectos por medio de algún procedimiento contable aprobado y
documentado. Una de las restricciones más comunes para numerosos
proyectos es la de disponer de un presupuesto limitado. Entre otros
ejemplos de restricciones se pueden citar las fechas de entrega requeridas,
los recursos especializados disponibles y las políticas de la organización.
 La EDT proporciona las relaciones entre todos los componentes y los
entregables del proyecto. Permite identificar las cuentas de control y cómo
puede agregarse el coste del proyecto a partir del coste de las actividades.
 El diccionario de la EDT proporciona información detallada sobre los
entregables y una descripción del trabajo requerido para producir cada
entregable en el ámbito de cada uno de los componentes de la EDT.
 Cronograma del proyecto: Indica cuándo y por cuánto tiempo son necesarios
qué recursos.
 Registro de riesgos: Han de considerarse los riesgos asociados a ciertas
actividades, con objeto de calcular los costes de mitigación y contingencias.
este proceso:
 Condiciones de mercado: Términos y condiciones para los recursos
materiales y servicios que será necesario adquirir. Para los recursos
propios, será necesario disponer de las tarifas de coste (si no, habrá que
estimarlas). Considerar la inflación en proyectos plurianuales.

Bases de datos de información publicadas comerciales: Existen bases de

datos disponibles con información sobre tarifas de recursos, precios de
materiales y equipos. También entran en esta categoría los precios de lista
publicados por los fabricantes.
en este proceso:
 Políticas de estimación de costes: La organización puede haber publicado
cierta normativa sobre cómo estimar los costes (p.ej., si hay que considerar
la inflación).
 Plantillas de estimación de costes: Para calcular los costes siguiendo el
formato corporativo.
 La información histórica y las lecciones aprendidas en proyectos similares
realizados con anterioridad. Si es posible, se recomienda entrevistarse con
las personas que participaron en aquellos proyectos.
 Estimación análoga: Consiste en usar las estimaciones de proyectos pasados
parecidos cuando son similares o no hay mucha información sobre el proyecto
actual. Es rápida y poco costesa, si bien puede no ser muy precisa. Por
ejemplo, podemos decir que estimamos que una actividad costará unos 1.000€
ya que es análoga a otra actividad similar de un proyecto anterior comparable.
 Estimación paramétrica: El coste de la actividad puede determinarse
cuantitativamente a partir de ciertas variables del proyecto. Por ejemplo, para
una instalación de cable, si los recursos asignados cuestan 25€ por metro, el
coste para instalar 100 metros sería de unos 2500€. Con esta técnica pueden
lograrse niveles más altos de exactitud, siempre y cuando la información
histórica sea precisa, los parámetros sean cuantificables y el modelo sea
escalable (para proyectos grandes y pequeños).
 Estimación ascendente (bottom-up): Cuando el coste de una actividad no
puede estimarse con un grado razonable de confianza, los costes dentro de
esa actividad se descomponen a un nivel mayor de detalle. Se estiman los
costes desglosados y luego se suman para obtener el coste total de la
actividad.
 Estimación por tres valores: Este método sirve para cuantificar el grado de
incertidumbre en las estimaciones. El coste esperado se aproxima a partir de la
media ponderada de 3 valores (optimista, más probable y pesimista). El grado
de confianza se expresa por medio de la desviación estándar: se dice que hay
un 68% de probabilidad de que el coste quede entre ±1σ, un 95% de
probabilidad entre ±2σ y un 99% de probabilidad entre ±3σ.

Para calcular rápidamente la desviación estándar, puede aproximarse con la

fórmula σ = (valor pesimista–valor optimista)/6. Por lo que respecta al coste
esperado, se puede aproximar de dos maneras:
 Si se utiliza una distribución de probabilidad beta (se hace así en el

método PERT), entonces coste esperado = (pesimista + 4*más
probable + optimista) / 6.
En el ejemplo, la actividad costará como mínimo 2000€, como máximo

3500€ y lo más probable es que cueste 2500€. Utilizando la distribución
beta, podríamos decir que se espera un coste entre 2350€ y entre
2850€ con una confianza del 68%, o bien entre 2100€ y 3100€ con una
confianza del 95%.
 Si por el contrario se utiliza una distribución de probabilidad triangular,

entonces duración esperada = (pesimista + más probable + optimista) /
3. En el mismo ejemplo, utilizando la distribución triangular, podríamos
decir que la duración estimada para es entre 24 y 29 días con una
confianza del 68%, o bien entre 22 y 32 días con una confianza del
95%.
Ejercicio 7. Su equipo de gestión está planificando dos paquetes de trabajo A y

B. A partir de la información que obtiene de los miembros de su equipo, usando el
método PERT, la estimación el paquete A es de 45000€ ± 300€ (confianza 65%) y la
estimación para el paquete B es de 65000€ ± 800€ (confianza 95%). ¿Cuál es la
estimación para la cuenta de control AB?
Solución:
 110.000€ ± 1.000€ (confianza 95%):

 Coste esperado de AB = 45000 + 65000 = 110.000€.
 Desviación de A = 300^2 = 90000.
 Desviación de B = (800/2) ^2 = 160000.
 Desviación de AB = 90000+160000 = 250000 (desviación de la suma =
suma de las desviaciones).

 Desviación estándar de AB = √250000 = 500€.

 Confianza 95% implica ± 2 σ = 500*2 = 1.000€.
Ejercicio 8. La tabla muestra los tres valores para las actividades de un

proyecto. Se pide calcular la estimación para el proyecto completo.
Solución:
 Nótese que se tienen en cuenta todas las actividades (no sólo las del camino
critico):
 El proyecto costará 208.783€ ± 9.247€ (confianza 68%)
 El proyecto costará entre 199.536€ y 218.030€ (confianza 68%)
 Análisis de Reservas: Las reservas son provisiones de fondos en el plan para
la dirección del proyecto para gestionar riesgos. Hay dos tipos de reservas. Las
reservas para contingencias forman parte de la línea base de costes: se
asignan a riesgos identificados que son aceptados y para los cuales se
desarrollan respuestas de contingencia (sirven para responder a los
imprevistos conocidos). La reserva de gestión no forma parte de la línea base
de coste: son fondos reservados para trabajos imprevistos dentro del alcance
del proyecto (sirven para responder a los imprevistos desconocidos).

Hay que tener en cuenta que responder a los imprevistos impacta no solo en
coste del proyecto, sino también en su duración. En la figura puede verse en
gris la línea base de coste de un proyecto (representando el presupuesto
mensual previsto). El incremento representado en color blanco representa la
reserva para contingencias. Como puede apreciarse, las reservas para
contingencias se pueden medir en coste y también en tiempo, y su efecto
podría llevarse al estimar las duraciones de las actividades.
 Software de estimación de costes para la gestión de proyectos: Existen

multitud de aplicaciones software de gestión de proyectos, hojas de cálculo
informatizadas, simulaciones y herramientas estadísticas que simplifican los
procesos de estimación y permiten cambiar los parámetros de manera ágil.
 Análisis de ofertas de proveedores: Cuando una parte del proyecto se adquiere

a un tercero (véase el capítulo 12), el equipo de gestión debe realizar un
análisis comparativo para determinar el coste de las actividades por parte del
proveedor que finalmente resulte adjudicatario. Por otra parte, debe estimarse
el coste interno (tareas de soporte, compras por parte del cliente, etc.) de las
actividades subcontratadas y otros costes no distribuibles.
 Técnicas grupales de toma de decisiones: Los enfoques grupales, tales como

la tormenta de ideas, la técnica Delphi o la técnica de grupo nominal, son útiles
para involucrar a los miembros del equipo en la mejora de la exactitud de la
estimación y de su nivel de compromiso con los resultados de las estimaciones
resultantes. Mediante la participación en el proceso de estimación de un grupo
estructurado de personas cercano a la ejecución técnica del trabajo, se
consigue información adicional y se obtienen estimaciones más precisas.
Además, cuando las personas se involucran en el proceso de estimación se
incrementa su compromiso con la consecución de los resultados estimados.

5.2.3. SALIDAS
 Estimaciones de costes de las actividades: Pueden presentarse de manera

resumida o detallada. Incluyen, por ejemplo:
 Costes directos (honorarios y otros costes variables asignables
directamente al proyecto)
 Materiales, equipamiento, servicios, instalaciones.
 Soporte por parte del departamento de TI.
 Determinadas categorías especiales, tales como: costes financieros
(intereses), factor de inflación, tasas de cambio de divisas, reservas para
contingencias de coste.
 Si se incluyen los costes indirectos en el proyecto, éstos se pueden incluir
en el nivel de la actividad o en niveles superiores.
 Base de las estimaciones: Documentación que explica cómo llegó a estas
estimaciones, incluyendo, entre otros apartados:
 Documentación de los fundamentos de las estimaciones (es decir, cómo
fueron desarrolladas).
 Documentación de los supuestos realizados.
 Documentación de las restricciones conocidas.
 Rango de las estimaciones y nivel de confianza de la estimación final
(recordar que, sin un ±, no es una estimación).
 Actualizaciones a los documentos del proyecto: Por ejemplo, como resultado
del análisis de reservas para contingencias, es posible que se requiera
actualizar el registro de riesgos.
5.3. Determinar el Presupuesto
Determinar el Presupuesto es el proceso que consiste en sumar los costes

estimados de las actividades individuales o paquetes de trabajo de cara a establecer
una línea base de costes autorizada. El beneficio clave de este proceso es que
determina la línea base de costes con respecto a la cual se puede monitorizar y
controlar el desempeño del proyecto.

Mientras que el proceso 7.2 Estimar los Costes tiene por objeto determinar
cuánto cuestan las actividades del proyecto, este proceso se centra en el proyecto
completo y en determinar cuándo se consumirá el presupuesto a lo largo del tiempo. El
presupuesto de un proyecto contempla todos los fondos autorizados para ejecutar el
proyecto. La línea base de costes es la versión aprobada del presupuesto del proyecto
desde la perspectiva de sus diferentes fases, pero no incluye las reservas de gestión.
5.3.1. ENTRADAS
 Plan de gestión de costes: Describe la manera en que se gestionarán y

controlarán los costes del proyecto.
 Línea base del alcance:
 Enunciado del alcance del proyecto: Las restricciones formales por periodo
relativas a los gastos de fondos del proyecto (p.ej., no está permitido gastar
más de 100k€ al mes) pueden ser exigidas por la organización, por
contrato, o por otras entidades como las agencias gubernamentales.
 Estructura de desglose del trabajo (EDT): Contiene las cuentas de control,
los paquetes de trabajo y las relaciones con los entregables y resto de
esfuerzos del proyecto.
 Diccionario de la EDT y su relación con los enunciados detallados del
trabajo del proyecto identifican los entregables y proporcionan una
descripción del trabajo a realizar para generar los entregables para cada
uno de los componentes de la EDT.

 Estimaciones de costes de las actividades: Los costes elementales de cada

actividad se suman para obtener los costes por paquete de trabajo.
 Base de las estimaciones: Información de soporte especificando los supuestos
básicos adoptados, la inclusión o exclusión de los costes indirectos y otros
costes del presupuesto del proyecto, etc.
 Cronograma del proyecto: Incluye las fechas planificadas de inicio y finalización
de las actividades del proyecto, los hitos, los paquetes de trabajo y las cuentas
de control. Esta información puede utilizarse para sumar los costes
correspondientes a los periodos del calendario en los cuales se ha planificado
incurrir dichos costes.
 Calendarios de recursos: Proporcionan información sobre qué recursos se
asignan al proyecto y en qué momento se asignan. Esta información se puede
utilizar para obtener el coste de los recursos a lo largo el proyecto.
 Registro de riesgos: Se debe revisar el registro de riesgos para tener en cuenta
los costes correspondientes a las respuestas a los riesgos.
 Acuerdos: La elaboración del presupuesto debe tener en cuenta la información
aplicable relativa a los contratos y otros acuerdos.
en este proceso:
 Políticas, procedimientos y guías existentes, tanto formales como
informales, relacionados con la elaboración de presupuestos de costes.
 Herramientas para la elaboración de presupuestos de costes.
 Métodos para la preparación de informes.
 Agregación de costes:
 Los costes a nivel de actividad se suman a nivel de paquete de trabajos.

 Los costes a nivel de paquete de trabajos se suman a nivel de cuentas de
control (lo cual facilita el control ejecutivo, a nivel de dirección).
 Los costes a nivel de cuenta de control se suman a nivel del proyecto
completo.
 Análisis de reservas: La línea base de costes incluye reservas para

contingencias, pero no incluye las reservas de gestión. Las reservas de
gestión:
 sí forman parte del presupuesto.
 no pertenecen al ámbito de control del director de proyectos, sino de la
Dirección.
 no se incluyen como parte de los cálculos de la medición del valor ganado.

 cuando se materializan riesgos desconocidos o cambios inesperados, el

director de proyectos pedirá a la Dirección que libere parte de esas
reservas.
 Juicio de expertos. El juicio de expertos puede provenir de diversas fuentes,

entre otras:
 Otras unidades dentro de la organización ejecutora: Han trabajado en
proyectos similares.
 Consultores: Han participado en muchos proyectos y tienen experiencia en
la elaboración de presupuestos.
 Interesados, incluyendo clientes: Pueden conocer ciertas reglas no escritas.
 Grupos del sector de actividad empresarial.
 Relaciones históricas: Series de datos de partida para usar en estimaciones

paramétricas o análogas.
 Conciliación del límite de financiación: Es necesario conciliar las estimaciones

de costes con las restricciones de plazo, supuestos, y límites de financiación. A
veces es necesario, por ejemplo, retrasar cierta actividad un mes más tarde
dado que no habrá fondos disponibles, lo que implica cambios en el
cronograma, equilibrado de recursos (resource smoothing), etc.
5.3.3. SALIDAS
 Línea base de costes: El coste acumulado del proyecto, proyectado en el

tiempo, suele representarse con una curva en S (ritmo de coste lento al
principio, más rápido en la fase intermedia y otra vez lento al final). El valor final
de coste corresponde con el presupuesto a la conclusión (Budget At
Completion –BAC-). Esta curva también se conoce como Planned Value. En la
técnica del valor ganado se utiliza para compararla con los costes reales,
previstos y completados.
En la figura de abajo se muestra la correspondencia entre presupuesto a la

finalización (BAC) y el presupuesto del proyecto:

 Requisitos de Financiación: Los requisitos de financiación totales y periódicos

(p.ej., trimestrales, anuales) se derivan de la línea base de costes. La línea
base de costes incluirá los gastos proyectados más las deudas anticipadas. A
menudo, la financiación tiene lugar en cantidades incrementales que no son
continuas y que pueden no estar distribuidas de manera homogénea, por lo
que se representan en una gráfica de escalón. Los fondos totales necesarios
son aquellos incluidos en la línea base de costes más las reservas de gestión,
en caso de existir. Los requisitos de financiación pueden incluir las de dicha
financiación.
 Actualizaciones a los Documentos del Proyecto: Entre los documentos del

proyecto que pueden actualizarse, se incluyen:
 El registro de riesgos.
 La estimación de costes de las actividades.
 El cronograma del proyecto.
6. Creación y evaluación de los riesgos
La Gestión del Riesgo del Proyecto incluye los procesos para llevar a cabo la
planificación de la gestión de riesgos, así como la identificación, análisis, planificación
de respuesta y control de los riesgos de un proyecto. Los objetivos de la gestión de los
riesgos del proyecto consisten en aumentar la probabilidad y el impacto de los eventos
positivos, y disminuir la probabilidad y el impacto de los eventos negativos en el
proyecto.

Los riesgos son consustanciales a cualquier proyecto. El proyecto más valioso

para la organización ejecutora, para quien lo dirige, para quien lo ejecuta, para quien
está involucrado de alguna manera, suele ser también el más incierto: hay mucho más
en juego, mucho que ganar pero también mucho que perder. En los tiempos que
corren, las empresas ya no van a ganar cuota de mercado o adelantar a la
competencia si no se arriesgan. Los proyectos que arriesgan poco deberían ceder
recursos a los que arriesgan mucho. Como dice Tom DeMarco: “Si un proyecto no
tiene riesgos, no lo haga”. La Gestión de Riesgos es el proceso de pensar en acciones
correctivas antes de que los problemas ocurran, mientras son meras abstracciones.
Un riesgo negativo, o amenaza, es un evento futuro posible que produciría un
resultado no deseado. También suele emplearse la palabra riesgo para designar al
efecto mismo no deseado, en lugar de la causa. A veces se usa esta definición
circular, muy gráfica: Un riesgo es un problema que aún no ha ocurrido. Un problema
es un riesgo que se ha materializado. Para el director de proyectos, cualquier cosa que
no tiene derecho a creer, es un riesgo. La asociación entre gestión de riesgos y “el
derecho a creer” se la debemos a Tom DeMarco, que define así la gestión de riesgos:
“Gestión de Riesgos es la ciencia que se ocupa de creer solo lo que se tiene derecho
a creer”.
Un director de proyectos sabe que en su proyecto habrá problemas, ¡si no, no

sería un proyecto! Quiere tener problemas, pero no quiere tener crisis. Quiere
gestionar cuando hay tiempo, cuando hay opciones. No confía en la improvisación.
Improvisar es la peor manera de gestionar. Lo contrario a gestión de riesgos se llama
gestión de crisis: tratar de descubrir qué hacer con los problemas después de que
ocurren.
La palabra riesgo es sinónimo de incertidumbre. Gestionar riesgos consiste en

anticiparse a esos eventos inciertos, para no tener que improvisar si es que ocurren.
Es importante anticiparse a los problemas, gestionando los riesgos negativos o
amenazas, y es importante anticiparse a los beneficios, gestionando los riesgos
positivos u oportunidades. Al director de Proyectos no le gusta verse sorprendido por
los problemas, pero tampoco quiere que le sorprenda un éxito inesperado, quiere verlo
venir. Un director de proyectos no debería tener miedo a los riesgos, sino todo lo
contrario. Hay que ver los riesgos como oportunidades, incluso cuando se trata de
amenazas.
Una característica que define la madurez de las personas es la facultad para

hacer frente a los problemas de la vida, desde los más nimios a los devastadores. Un
niño pequeño tiene excusa para no pensar en la amenaza nuclear, la degradación del
medio ambiente, secuestros, injusticias, violaciones, etc. Pero como padres tenemos
que pensar en todo eso. De forma análoga, podríamos decir que gestión de riesgos es
gestión de proyectos para adultos. Los directores de proyectos con experiencia no
tienen una visión optimista de que todo va a salir de color rosa en el proyecto. Ya han
vivido muchos problemas en el pasado y saben que los problemas de ayer son los
riesgos de hoy.

Esto no significa que tengan una visión negativa o pesimista del proyecto, sino
que quieren separar qué se sabe con certeza de aquello que es dudoso, y si esto
último puede perjudicar a los objetivos del proyecto, lo correcto es gestionar
anticipadamente, cuando hay opciones.
Como todo el mundo sabe, gestionar riesgos cuesta dinero. A continuación se

describen las respuestas típicas para un riesgo negativo, o amenaza:
 Avoid (evitar, sortear, prevenir, anular): no haciendo lo que provoca el riesgo,

pero entonces también se deja de ganar el beneficio que supone la oportunidad
de hacerlo.
 Contain (contener, aceptar de forma activa): reservar tiempo y dinero suficiente
por si ocurre. En la práctica, no tiene mucho sentido contener un solo riesgo,
sino el conjunto completo. Algunos se materializarán y otros no. La estrategia
de contención consiste en reservar los recursos suficientes, en media, para
compensar los riesgos que puedan materializarse.
 Mitigate (mitigar): tomar medidas antes de su materialización para reducir los
eventuales costes de contención. Se anticipan los pasos necesarios para que
la estrategia de contención elegida sea implementable en el momento de la
transición. También estamos mitigando cuando transferimos un riesgo a un
tercero, por ejemplo, al contratar un seguro.
 Evade (asumir, aceptar de forma masiva, o lo que es lo mismo: cruzar los
dedos para que no ocurra): Esta es la única respuesta que no cuesta dinero,
pero solo si no ocurre el problema, porque si ocurre, el impacto puede llegar a
ser extraordinario.
Para explicar estas respuestas a amenazas con un ejemplo, imaginemos que

mi hijo de 5 años está aprendiendo a montar en bicicleta. Lleva un tiempo practicando
con dos ruedas y parece que mantiene bien el equilibrio. Está tomando confianza,
quizá demasiada, va demasiado rápido, ya no le puedo seguir corriendo... Identifico el
riesgo de que se caiga y se fracture la cabeza, por ejemplo. Ahora voy a gestionar este
riesgo eligiendo una de estas posibles respuestas:
 Avoid: (evitar): Lo más sencillo es prevenir el riesgo totalmente (o evitar el

riesgo). Puedo decirle “Arturo, te prohíbo terminantemente montar en bici
nunca más”. No me gusta esta decisión por el alto coste en su desarrollo físico,
social y psicológico, en nuestra relación padre-hijo, etc.
 Contain (contener): Puedo comprar un botiquín de primeros auxilios y atenderle
rápidamente si se cae, me aseguro de que podría llevarle al hospital en menos
de 15 minutos.
 Mitigate (mitigar): Puedo comprarle un casco y hacer que se lo ponga. Tengo el
riesgo residual de que se lastime las rodillas. También pueden aparecer
riesgos secundarios: ¿el casco le restará visibilidad? ¿le provocará una
reacción alérgica?

 Evade (asumir): ¡Bah, para qué preocuparse! Cuando yo tenía su edad ya

íbamos en bici por las carreteras y nunca pasaba nada. Además, todo el
mundo sabe que los niños son de goma. Si se cae, se araña un poco pero está
bien que aprenda la lección. No le vendría mal coger un poco de miedo...
La última respuesta al riesgo es la más económica, sin duda, pero... ¿No me

estaré autoengañando? ¿Tengo derecho a creer que no voy a tener un problema?
Por lo que respecta a las oportunidades, ¿cómo se deben gestionar? Veámoslo

con otro ejemplo. Imaginemos que somos el proveedor de una herramienta de gestión
de proyectos. Nos enteramos de que un potencial cliente publica un concurso para
adquirir un servicio de PMO, y pide oferta a cinco empresas de consultoría. Una de
ellas nos propone subcontratar nuestra herramienta dentro de su oferta. Así pues, es
probable que vendamos nuestra herramienta: identificamos una oportunidad. Ahora
podemos gestionar esa oportunidad decidiendo la mejor respuesta:
 Podemos aceptar la oportunidad, esto es, no hacer nada porque confiamos que
esta empresa será adjudicataria y después negociaremos. Aunque sea una
respuesta pasiva, estamos gestionando: decidimos que lo más adecuado es
esperar.
 Podemos mejorar la oportunidad, si adelantamos algunas funcionalidades que
estaban previstas para la siguiente versión de la herramienta, que la hacen
más adecuada para prestar servicios de PMO, y cerramos un acuerdo a un
mayor precio con la empresa consultora.
 Podemos explotar la oportunidad, si llegamos a un acuerdo de colaboración
con las cinco consultoras, es seguro que venderemos nuestra herramienta. Ya
no hay más incertidumbre.
 Podemos compartir la oportunidad, si nos aliamos con otro proveedor de
herramientas competidor nuestro, al que también es probable que subcontraten
las otras consultoras, por ejemplo.
Muchos proyectos fracasan porque, de repente, ocurre un problema inesperado

que lleva a cancelar el proyecto. Nos convencemos a nosotros mismos de que
estamos gestionando riesgos porque tenemos una lista de riesgos y la revisamos en
cada reunión de seguimiento, pero no pensamos en los riesgos importantes, esos que
si ocurren hacen que el proyecto ya no se justifique. En palabras de Tom DeMarco:
“Muchas veces nos ocupamos de no tropezar con los raíles, pero no vemos el tren que
se acerca.”

Algunos casos que ilustran esos riesgos del tipo “tren que se acerca”:
1. Un proyecto de consultoría de ayuda al desarrollo de pequeñas y medianas

empresas de Egipto, financiado por el gobierno, tuvo que cancelarse en marzo
de 2011, después de las revueltas que derrocaron a Hosni Mubarak. Los
miembros del comité de dirección de Madrid se vieron sorprendidos por la
cancelación.
2. Un proyecto de desarrollo software en Chile acabó siendo un fracaso financiero
porque el contratista principal nos hizo responsables de fallos funcionales. Esto
sorprendió al equipo de dirección del proyecto, que siempre asumió que
nuestra responsabilidad quedaba restringida al plano técnico.
3. Otro caso, todo un clásico en gestión de riesgos, es el caso del aeropuerto de
Denver, que tuvo que esperar 15 meses para empezar a operar (lo que supuso
unas pérdidas de 500 M$) debido al retraso inesperado en la entrega del
sistema software que gestionaba el equipaje de los viajeros.
El caso del aeropuerto de Denver fue especialmente notorio en los años 90,
cuando se acuñó la expresión “la crisis del software”: se aseguraba que el 70% del
software no se usaba nunca. El equipo de dirección del nuevo aeropuerto planificó su
apertura el 31 de octubre de 1993, pero finalmente abrió sus puertas 15 meses más
tarde, después de 500$ millones de sobrecoste. El día señalado, todo estaba
completado excepto el sistema Automático de Gestión de Equipajes (Automated
Baggage Handling System: ABHS).

Un análisis en profundidad habría descubierto que el fallo principal se no se

debió al proceso software, sino a la deficiente gestión de riesgos:
 No se identificaron apropiadamente los riesgos: El equipaje de los de los

viajeros se haría llegar hasta las puertas de embarque a través de unos largos
túneles. El movimiento del equipaje estaría completamente automatizado por
tele-carritos, lectores de código de barras, dispositivos de escaneo,
descargadores automáticos, etc. Cualquier lista de riesgos habría incluido el
retraso en la entrega del software como un riesgo significativo. Sin el ABHS no
se podía procesar el equipaje, y por tanto no se podía abrir el aeropuerto.
 No se analizaron apropiadamente los riesgos: Como ABHS estaba en el
camino crítico, su retraso retrasaría igualmente la apertura del aeropuerto,
provocando unas pérdidas mensuales de 33$ millones. Cualquier análisis
habría descubierto que era uno de los riesgos más importantes del proyecto.
 No se respondieron adecuadamente los riesgos: La estrategia de mitigación
evidente habría sido mover la entrega del software ABHS fuera del camino
crítico. Los túneles podrían haberse remodelado para que fueran practicables
por personas que pudieran transportar el equipaje manualmente. Unos pocos
millones de dólares gastados en un esquema alternativo de gestión de
equipajes habría ahorrado 500$ millones de los contribuyentes.
Los problemas de ayer son los riesgos de hoy: El aeropuerto de Múnich había
implantado un sistema parecido pero asignaron 2 años de pruebas, y convivencia con
el sistema antiguo durante 6 meses para afinar el sistema nuevo. El equipo de Denver
pidió consejo y aconsejaron hacer lo mismo.
No tenían derecho a creer que el software terminaría en plazo: Ya los licitantes

advirtieron del riesgo en sus propuestas. Se contrató a BAE Automated Systems
porque ofrecían menor plazo. Durante la ejecución, el proveedor advirtió repetidas
veces del potencial retraso, al introducirse cada mes nuevos cambios. Todas las
partes eran conscientes de que se trataba de hacer un proyecto de 4 años en 2.
¿Qué tendría que haber hecho mejor el equipo de gestión? Deberían haber
realizado un análisis cuantitativo del riesgo. En la figura puede verse en gris la línea
base de coste del proyecto (representando el presupuesto mensual previsto). El
incremento representado en color blanco representa la reserva para contingencias.

Imaginemos ahora que el equipo de dirección del proyecto hubiera gestionado

los riesgos como es debido y hubiera propuesto un plan de respuesta para mitigar el
retraso del software con un sistema alternativo de gestión de equipajes basado en
remodelar los túneles para que fueran practicables por personas. En la figura de la
izquierda puede observarse la línea base de coste resultante si se materializa el
riesgo: el presupuesto del proyecto más el coste por inactividad de 500$ millones
durante 15 meses. En la figura de la derecha se ha representado la nueva línea base
de coste considerando el coste de la mitigación.
Este análisis cuantitativo del riesgo es muy elocuente. ¿Algún responsable se

negaría a dotar el presupuesto con los fondos adicionales? Es posible que el dinero y
el tiempo se malgaste si finalmente no ocurre el problema pero… ¿Tienen derecho a
creer que la entrega de software no se va a retrasar? En el peor caso, si se decide
asumir el riesgo, sería una decisión madurada y consciente. Si el riesgo se materializa
¡ya no es culpa del director del proyecto!

Los pasos que debe seguir el equipo de dirección del proyecto para gestionar
los riesgos vienen descritos en el capítulo 11 de la Guía del PMBOK®:
11.1 Planificar la Gestión de los Riesgos: Al comenzar el proyecto hay que establecer
las reglas de gestión de riesgos, que estarán muy influenciadas por el tipo de
organización ejecutora y su perfil de aversión o propensión al riesgo. Lo que para una
empresa muy conservadora supondría un riesgo, ¿lo sería para una start-up? Por otra
parte, las empresas ya suelen contar con ciertos activos de procesos que es
obligatorio seguir (flujos, plantillas de documentos, categorías de riesgos, etc.)
11.2 Identificar los Riesgos: Los riesgos agregados negativos, si ocurren, hacen que el
proyecto fracase. La razón por la cual se gestionan los riesgos es para reducir o
eliminar la posibilidad de estos fracasos globales, pero estos riesgos agregados no se
gestionan directamente. La parte esencial de la gestión de riesgos es trabajar sobre
los riesgos elementales o causales (esto es, el conjunto de eventualidades que
pueden salir mal y acabar produciendo un fallo agregado). Por ejemplo, en nuestro en
el caso práctico desarrollado en el anexo, el proyecto traducir un libro, un riesgo
agregado sería retrasarse un par de meses, o que la traducción no fuera aceptable en
las comunidades del PMI. Estos riesgos globales se descomponen en riesgos
elementales para poder ser gestionados, como: ¿cuál será la velocidad del equipo en
la fase de traducción? ¿Se perderán textos traducidos por borrado accidental?
¿Causará baja de algún voluntario? ¿Pedirán demasiados cambios los revisores
externos del PMI?, etc. Estos riesgos gestionables se identifican por el equipo para su
posterior análisis.
11.3 Realizar el Análisis Cualitativo de Riesgos: No es posible gestionar una lista muy
larga de riesgos, hay que priorizar. La forma más sencilla de ordenar los riesgos es por
el producto de probabilidad por impacto considerando valores ordinales. Por ejemplo,
un riesgo muy probable pero de muy bajo impacto suele ser menos prioritario que un
riesgo de prioridad media e impacto medio.
11.4 Realizar el Análisis Cuantitativo de Riesgos: Sobre determinados riesgos, es

necesario determinar el rango de incertidumbre en tiempo y coste. Es el caso cuando
tenemos que convencer al comité de seguimiento que hay que usar, por ejemplo
10.000 € de las reservas de gestión para disminuir la exposición del proyecto en
50.000 € y adelantar 2 semanas la fecha más probable de finalización.
11.5 Planificar la Respuesta a los Riesgos: Decidir las respuestas para las
oportunidades y las amenazas.
11.6 Controlar los Riesgos: Implementar las respuestas y mantener la gestión de

riesgos actualizada.


a la derecha.
1 Supuesto A Una técnica analítica para determinar las características y relaciones esenciales de los
componentes en el plan para la dirección del proyecto a fin de establecer una reserva para la
duración del cronograma, el presupuesto, los costes estimados o los fondos para un proyecto.
2 Contingencia B Un riesgo que tendría un efecto positivo sobre uno o más objetivos del proyecto.
3 Estrategias de C Una cuadrícula para vincular o mapear la probabilidad de cada ocurrencia de riesgo y su impacto
Respuesta a sobre los objetivos del proyecto en caso de que ocurra dicho riesgo.
Contingencias
4 Análisis del Valor D Un punto o asunto cuestionado o sobre el que existe una controversia, o que no se ha resuelto y
Monetario Esperado se está analizando, o en el que existen posiciones opuestas o desacuerdo.
(EVM)
5 Plan de Contingencia E Examinar y documentar la efectividad de las respuestas a los riesgos en el tratamiento de los
riesgos identificados y sus causas raíz u originarias, así como de la efectividad del proceso de
gestión de riesgos.
6 Incidente F Riesgo que permanece después de haber implementado las respuestas a los riesgos.
7 Análisis de Monte G Una técnica estadística que calcula el resultado promedio cuando el futuro incluye escenarios que
Carlo pueden ocurrir o no. Esta técnica se usa comúnmente dentro del análisis del árbol de decisiones.
8 Oportunidad H Los planes de contingencia incluyen un conjunto alternativo de acciones y tareas disponibles en
caso de que el plan principal deba ser abandonado debido a incidentes, riesgos u otras causas.
9 Matriz de I El grado de incertidumbre que una entidad está dispuesta a aceptar, con miras a una recompensa.
Probabilidad e
Impacto
10 Reserva J Respuestas proporcionadas que pueden utilizarse en caso de que ocurra un evento disparador
específico.
11 Análisis de Reservas K Provisión de fondos en el plan para la dirección del proyecto para mitigar riesgos del cronograma
y/o costes.
12 Riesgo Residual L Un evento o una ocurrencia que podría afectar la ejecución del proyecto y que puede tenerse en
cuenta con una reserva.
13 Aceptar el Riesgo M Un factor del proceso de planificación que se considera verdadero, real o cierto, sin prueba ni
demostración.
14 Propensión al Riesgo N Técnica que calcula o itera el coste del proyecto o el cronograma del proyecto muchas veces
utilizando valores de entrada seleccionados al azar a partir de distribuciones de probabilidad de
costes o duraciones posibles, para calcular una distribución de los costes totales del proyecto o
fechas de conclusión posibles.
15 Auditorías de los O Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto decide reconocer el
Riesgos riesgo y no tomar ninguna medida a menos que el riesgo ocurra.
Solución al Ejercicio 1: 1-M, 2-L, 3-J, 4-G, 5-H, 6-D, 7-N, 8-B, 9-C, 10-K, 11-A, 12-F,
13-O, 14-I, 15-E.


a la derecha.
1 Evitar el Riesgo A Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto traslada el impacto
de una amenaza a un tercero, junto con la responsabilidad de la respuesta.
2 Evaluación de la B Una técnica de análisis cuantitativo de riesgos y de modelado utilizada para ayudar a determinar
Calidad de los Datos qué riesgos presentan el mayor impacto posible sobre el proyecto. Este método evalúa el grado
sobre Riesgos en que la incertidumbre de cada elemento del proyecto afecta al objetivo que está siendo
examinado cuando todos los demás elementos inciertos son mantenidos en sus valores de
referencia. La representación habitual de los resultados es un diagrama con forma de tornado.
3 Mitigar el Riesgo C El grado, cantidad o volumen de riesgo que resistirá una organización o individuo.
4 Reevaluación de los D La reevaluación de los riesgos es la identificación de nuevos riesgos, la reevaluación de los riesgos
Riesgos actuales y el cierre de riesgos obsoletos.
5 Registro de Riesgos E Riesgo que tendría un efecto negativo sobre uno o más objetivos del proyecto.
6 Umbral de Riesgo F Análisis de Fortalezas, Oportunidades, Debilidades y Amenazas de una organización, proyecto u
opción.
7 Tolerancia al Riesgo G Un documento en el cual se registran los resultados del análisis de riesgos y de la planificación de
la respuesta a los riesgos.
8 Transferir el Riesgo H Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto actúa para eliminar
la amenaza o proteger al proyecto de su impacto.
9 Evaluación de la I Tipo especial de diagrama de barras utilizado en análisis de sensibilidad para comparar la
Urgencia de los importancia relativa de las variables.
Riesgos
10 Riesgo Secundario J Revisión y determinación del momento en que puedan ser necesarias acciones antes que ocurran
otros elementos de riesgo.
11 Análisis de K Medida del nivel de incertidumbre o el nivel de impacto en el que un interesado pueda tener
Sensibilidad particular interés. Por debajo, la organización aceptará el riesgo. Por encima, la organización no
tolerará el riesgo.
12 Análisis DAFO L Evento o situación que indica que un riesgo está próximo a ocurrir.
13 Amenaza M Técnica para evaluar el grado en que los datos sobre riesgos son útiles para la gestión de riesgos.
14 Diagrama con Forma N Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto actúa para reducir la
de Tornado probabilidad de ocurrencia o impacto de un riesgo.
15 Condición O Un riesgo que surge como resultado directo de la implantación de una respuesta a los riesgos.
Disparadora
Solución al Ejercicio 2: 1-H, 2-M, 3-N, 4-D, 5-G, 6-K, 7-C, 8-A, 9-J, 10-O, 11-B, 12-F,
13-E, 14-I, 15-L.
Procesos del área de Gestión de los Riesgos del Proyecto

Gestión de los Riesgos del Proyecto tiene procesos en los grupos de planificación y


Gestión de los Riesgos del Proyecto, que se definen así:
11.1 Planificar la Gestión de los Riesgos: Definir cómo realizar las actividades de
gestión de riesgos de un proyecto).
11.2 Identificar los Riesgos: Determinar los riesgos que pueden afectar al proyecto y
documentar sus características.
11.3 Realizar el Análisis Cualitativo de Riesgos: Priorizar los riesgos para análisis o
acción posterior, evaluando y combinando la probabilidad de ocurrencia e impacto de
dichos riesgos.
11.4 Realizar el Análisis Cuantitativo de Riesgos: Analizar numéricamente el efecto de

los riesgos identificados sobre los objetivos generales del proyecto.
11.5 Planificar la Respuesta a los Riesgos: Desarrollar opciones y acciones para

mejorar las oportunidades y reducir las amenazas que afecten a los objetivos del
proyecto.
11.6 Controlar los Riesgos: Implementar los planes de respuesta a los riesgos,
monitorizar los riesgos identificados, monitorizar los riesgos residuales, identificar
nuevos riesgos y evaluar la efectividad del proceso de gestión de los riesgos a través
del proyecto.


de Gestión de los Riesgos del Proyecto:

Documentos del área de Gestión de los Riesgos del Proyecto

Riesgos del Proyecto:


Proyecto

6.1. Planificar la Gestión de Riesgos
Planificar la Gestión de Riesgos es el proceso de definir cómo realizar las

actividades de gestión de riesgos de un proyecto. El beneficio clave de este proceso
es que asegura que el nivel, el tipo y la visibilidad de la gestión de riesgos son acordes
tanto con los riesgos como con la importancia del proyecto para la organización. El
plan de gestión de riesgos es vital para comunicarse y obtener el acuerdo y el apoyo
de todos los interesados a fin de asegurar que el proceso de gestión de riesgos sea
respaldado y llevado a cabo de manera eficaz a lo largo del ciclo de vida del proyecto.
Este proceso debe iniciarse tan pronto como se concibe el proyecto y debe
completarse en las fases tempranas de planificación del mismo.
El plan de gestión de riesgos es un componente del plan para la dirección del

proyecto. Documenta cómo se llevará a cabo la gestión de los riesgos del proyecto. Es
decir, determina cómo diseñar, implementar y controlar el conjunto de actividades para
gestionar los riesgos del proyecto. Por ejemplo, se decidirá cómo se identificarán los
riesgos, cómo se asignarán los valores de probabilidad e impacto, cómo se
determinarán las estrategias de respuesta, qué tratamiento se les dará a los riesgos de
importancia alta, media y baja, cómo se llevarán a cabo las tareas de supervisión y
monitorización, etc.

6.1.1. ENTRADAS
 Plan para la dirección del proyecto: Al planificar la gestión de riesgos se deben

tener en cuenta todos los planes secundarios de gestión y las líneas base. Por
ejemplo:
 La línea base de costes indicará la reserva para contingencias para
imprevistos conocidos, el presupuesto incluirá la reserva de gestión para
imprevistos desconocidos. A mayor riesgo del proyecto, mayor provisión de
reservas.
 La línea base de cronograma expresará la duración del proyecto, la
concentración de las actividades, las holguras, los hitos, etc. Todo esto
dará una idea sobre si el proyecto tiene riesgo de retraso.
 El plan de gestión de las comunicaciones se indicará la complejidad de las
comunicaciones (número de canales, métodos y herramientas), lo que dará
una idea sobre la complejidad de la gestión del proyecto.
 El enunciado del alcance del proyecto puede incluir riesgos inherentes si
los entregables son muy numerosos, o técnicamente complejos.
 Acta de constitución del proyecto: Puede proporcionar varias entradas tales

como los riesgos de alto nivel, las descripciones del proyecto de alto nivel y los
requisitos de alto nivel.
 Registro de interesados: Contiene todos los detalles relacionados con los
interesados del proyecto, proporciona una visión general de sus roles, poder,
interés, conocimiento y estrategia de gestión. A más interesados con intereses
contrapuestos, mayor riesgo del proyecto.
 Factores Ambientales de la Empresa: Es necesario adaptar la gestión de los
riesgos (sobre todo para saber cómo han de comunicarse) a la actitud de la
organización ante el riesgo (si el perfil es conservador, neutro, favorable o
tolerante a los riesgos). Entre los factores ambientales que influyen en la
actitud hacia el riesgo, se encuentran:
 La propensión al riesgo (risk appetite): El grado de incertidumbre que una
entidad está dispuesta a aceptar, con miras a una recompensa.
 La tolerancia al riesgo (risk tolerance): El grado, cantidad o volumen de
riesgo que resistirá una organización o individuo.
 El umbral de riesgo (risk threshold): Medida del nivel de incertidumbre o el
nivel de impacto en el que un interesado pueda tener particular interés. Por
debajo de ese umbral de riesgo, la organización aceptará el riesgo. Por
encima de ese umbral de riesgo, la organización no tolerará el riesgo.

Según Tom DeMarco, una organización que se precie de tener madurez en

gestión de riesgos, debería responder afirmativamente, para cada uno de sus
proyectos, a estas nueve preguntas:
¿Hay un registro de riesgos publicado? ¿Contiene dicha lista los riesgos causales más
importantes, no sólo los pocos riesgos que todos tememos? ¿Es visible para todos los que
1.
trabajan en el proyecto? ¿Hay suficientes riesgos en la lista como para indicar un análisis
cuidadoso de riesgos?
¿Hay un mecanismo continuo para descubrir nuevos riesgos? ¿Los participantes se sienten
2.
seguros al declarar riesgos?
¿Son algunos de los riesgos de la lista potencialmente fatales? (concentrarse sólo en los riesgos
3. fácilmente gestionables es una forma de menospreciar la gestión de riesgos. Son los fatales los
que necesitan su atención más cuidadosa).
4. ¿Se cuantifica cada riesgo en probabilidad e impacto de coste y tiempo?
5. ¿Cada riesgo tiene asociado un factor desencadenante, o disparador? ¿Se monitorizan?
¿Hay una persona responsable de gestión de riesgos? (cuando la actitud es que todo el mundo
6. es responsable de gestionar riesgos, al final nadie es responsable, dado que todos ellos tienen
trabajo de verdad que atender).
¿Hay trabajos en la EDT que puede que no tengan que hacerse? (la ausencia de estos trabajos
7.
condicionales es una señal de que no hay planes de contingencia).
¿Tiene el esfuerzo total una estimación y un objetivo, y son diferentes? (la fecha más
8. temprana en la que el trabajo podría terminar es un excelente objetivo, pero es una mala
estimación).
¿Hay una probabilidad significativa de terminar bastante antes de la fecha estimada? (si no hay
9. una probabilidad razonable de terminar un 20-30% antes que la estimación, entonces la
estimación coincide con el objetivo).
 Activos de los Procesos de la Organización: Hay que revisar las políticas y

procedimientos ya disponibles en la organización para no reinventarlos. Estos
activos incluyen, entre otros:
 Categorías de riesgos: A veces, la organización maneja representaciones
jerárquicas de los riesgos según sus categorías en una Estructura de
Desglose de Riesgos (Risk Breakdown Structure –RBS).
 Definiciones comunes de conceptos y términos.
 Formatos de declaración de riesgos.
 Plantillas estándar.
 Roles y las responsabilidades.
 Niveles de autoridad para la toma de decisiones.

 Técnicas analíticas: Se usan para evaluar la exposición al riesgo estratégico

del proyecto en combinación con las actitudes de los interesados. En función
de estas evaluaciones, el equipo del proyecto puede asignar los recursos
adecuados y centrarse en las actividades de gestión de riesgos.
 Juicio de expertos: Pueden ayudar a definir el plan de gestión de riesgos, entre
otros:
 La alta dirección.
 Los interesados.
 Otros directores de proyectos de proyectos análogos.
 Expertos en la materia.
 Grupos del sector y asesores.
planificación para desarrollar el plan de gestión de riesgos, invitando a
cualquier persona de la organización con la responsabilidad de gestionar la
planificación y ejecución de actividades relacionadas con los riesgos. En estas
reuniones se define, por ejemplo, cómo se gestionaran los riesgos en relación
con el presupuesto y el cronograma, cómo se establecerán y aplicarán las
reservas para contingencias, cómo se repartirán las responsabilidades en
materia de riesgos, qué plantillas se usarán, etc.
6.1.3. SALIDAS
 Plan de gestión de riesgos: Describe el modo en que se estructurarán y se

llevarán a cabo las actividades de gestión de riesgos. Puede incluir:
 Metodología para llevar a cabo la gestión de riesgos en el proyecto.
 Roles y responsabilidades.
 Presupuesto: A partir de los recursos asignados, se estiman los fondos
necesarios para su inclusión en la línea base de costes, y se establecen los
protocolos para la aplicación de la reserva para contingencias y la reserva
de gestión.
 Calendario: Cuándo se llevarán a cabo los procesos de gestión de riesgos.
Protocolos para la utilización de las reservas de tiempos.
 Categorías de riesgo: Pueden organizarse en una Estructura de Desglose
de Riesgos (RBS).
 Definiciones de la probabilidad e impacto de los riesgos: Definiciones de las
escalas de probabilidad e impacto de los riesgos sobre los objetivos del
proyecto. Por ejemplo, para los objetivos de calidad, la escala de impacto
podría tener estos cinco valores, de menor a mayor:

1) Degradación apenas perceptible, 2) degradación sólo visible para

usuarios muy exigentes, 3) degradación aceptable por el patrocinador, 4)
degradación inaceptable por el patrocinador, 4) degradación resultante en
un producto inservible.
 Matriz de probabilidad e impacto. Se usarán para ponderar cualitativamente
riesgos u oportunidades.
 Revisión de las tolerancias de los interesados.

 Formatos de los informes.
 Seguimiento: Se documenta cómo se registrarán las actividades de gestión
de riesgos y cómo se auditarán los procesos de gestión de riesgos.
6.2. Identificar los Riesgos
Identificar los Riesgos es el proceso de determinar los riesgos que pueden

afectar al proyecto y documentar sus características. El beneficio clave de este
proceso es la documentación de los riesgos existentes y el conocimiento y la
capacidad que confiere al equipo del proyecto para anticipar eventos. En la
identificación de riesgos participan: El director del proyecto, el equipo del proyecto, el
comité de gestión de riesgos (si existe), y los expertos (analistas, consultores, clientes,
usuarios, otros directores de proyectos, etc.). La responsabilidad de la identificación de
los riesgos recae sobre el director del proyecto y también sobre los miembros del
equipo. Es un proceso iterativo que continua hasta el final del proyecto.

6.2.1. ENTRADAS
 Plan de gestión de riesgos: Contiene las asignaciones de roles y

responsabilidades en materia de riesgos, el presupuesto y tiempo asignado
para gestionar riesgos, y las categorías de riesgos.
 Plan de gestión de costes: Proporciona procesos y controles que se pueden
utilizar para ayudar a identificar los riesgos a lo largo del proyecto.
 Plan de gestión del cronograma: Proporciona conocimiento sobre los objetivos,
expectativas e incertidumbres relativos al cronograma del proyecto.
 Plan de gestión de calidad: Proporciona una línea base de medidas y métricas
de calidad aplicables a la identificación de riesgos.
 Plan de gestión de recursos humanos: Pueden ser fuentes de incertidumbre el
modo de adquirir los recursos, los roles y responsabilidades, el organigrama
del proyecto, la carga de perfiles prevista por mes, etc.
 Línea base del alcance: Incluye las restricciones, los supuestos, e información
sobre los entregables y su complejidad técnica.
 Estimación de costes de las actividades: Proporcionan la base para las
estimaciones e idealmente expresan el rango de incertidumbre sobre el coste
de cada actividad.
 Estimación de duración de las actividades: Proporcionan la base para las
estimaciones e idealmente expresan el rango de incertidumbre sobre la
duración de cada actividad.
 Registro de interesados: ¿Tenemos derecho a creer que los interesados clave
alcanzarán sus expectativas y permitirán cerrar el proyecto? ¿que aquellos
cuya involucración es necesaria colaborarán de forma efectiva? ¿que los que
se oponen al proyecto no lo harán inviable?

 Documentos del proyecto: Ejemplos de documentos que permiten identificar

mejor los riesgos:
 Acta de constitución del proyecto.
 Cronograma del proyecto.
 Diagramas de red del cronograma.
 Registro de incidentes.
 Lista de verificación de calidad.
 Documentos de las adquisiciones: Describen los trabajos a externalizar y
proporcionan otra fuerte importante de incertidumbre. ¿Tenemos derecho a
creer que este tipo de contrato para este servicio es el más apropiado? ¿que el
desempeño de este proveedor será el adecuado? ¿que no iremos a juicio?
 Información publicada, incluyendo bases de datos comerciales.
 Investigaciones académicas.
 Listas de control publicadas.
 Estudios comparativos.
 Estudios del sector.
 Actitudes frente al riesgo.
en este proceso:
 Archivos de proyectos anteriores, incluidos los datos reales (los problemas
de ayer son los riesgos de hoy).
 Controles de los procesos de la organización y del proyecto.
 Formatos o plantillas de declaración de riesgos.
 Revisiones a la documentación: Una lectura comprensiva de los documentos

del proyecto permitirá deducir incertidumbres sobre el alcance, los entregables,
etc. También servirá para descubrir riesgos inherentes en caso de que los
documentos sean inconsistentes, incompletos o de mala calidad.
 Técnicas de recopilación de información:
 Tormenta de ideas: El objetivo de la tormenta de ideas es obtener una lista
completa de los riesgos del proyecto. Bajo el liderazgo de un facilitador, se
generan ideas sobre los riesgos del proyecto, ya sea por medio de una
sesión tradicional y abierta de tormenta de ideas, o en una sesión
estructurada. Tom DeMarco sugiere una secuencia de brainstorming en
cuatro pasos para deducir riesgos del tipo “tren que se acerca”: 1) imaginar
un resultado catastrófico; 2) describir el escenario; 3) analizar la causa que
lleva a ese escenario; 4) ponerle un nombre a esta causa, que
seguramente pueda ser un riesgo bien deducido.


Si la incertidumbre no está bajo el control del equipo de dirección del
proyecto, o bien no es posible una respuesta proactiva, entonces se
considera un supuesto.
 Técnica Delphi: Es una manera de lograr un consenso de expertos. Los
expertos en riesgos del proyecto participan en esta técnica de forma
anónima. Un facilitador utiliza un cuestionario para solicitar ideas acerca de
los riesgos importantes del proyecto. Las respuestas son resumidas y
posteriormente enviadas nuevamente a los expertos para recabar
comentarios adicionales. En pocas rondas de este proceso se puede lograr
el consenso. La técnica Delphi ayuda a reducir sesgos en los datos y evita
que cualquier persona ejerza influencias indebidas en el resultado.
 Entrevistas: Se entrevista a los expertos para obtener sus impresiones
sobre los posibles riesgos.
 Análisis de causa raíz: Se analiza el porqué de los problemas hasta
determinar la causa raíz. Normalmente, un riesgo que puede identificarse
con la causa raíz de un problema.
 Análisis con listas de verificación: Puede revisarse la lista de categorías de
riesgos (o bien el Estructura de Desglose de Riesgos –RBS) para asegurar que
ninguna categoría de riesgos se ha olvidado.
Por ejemplo, en proyectos de desarrollo de software suele utilizarse esta lista

de las diez categorías de riesgos más frecuentes:
1. Requisitos ¿Qué es exactamente lo que el sistema tiene que hacer?

Adecuación ¿Cómo interaccionará el sistema con los operadores humanos y
2.
otros sistemas?
Entorno cambiante ¿Cómo cambiarán las necesidades y los objetivos durante el
3.
período de ejecución?
Recursos ¿Qué habilidades humanas clave estarán disponibles (cuando se
4.
necesiten) según avance el proyecto?
Dirección ¿Tendrá el equipo directivo el talento suficiente para favorecer la
creación de equipos productivos, mantener la moral elevada, la
5.
rotación baja y coordinar conjuntos complejos de tareas
interrelacionadas?
Cadena de
6. El desempeño de terceros, ¿será el esperado?
suministro
Política ¿Cuál será el efecto del uso del poder político para disfrazar la
7. realidad e imponer restricciones inconsistentes con la finalización
exitosa del proyecto?
Conflictos ¿Cómo resolverán los miembros de una comunidad diversa de
8.
interesados sus objetivos mutuamente incompatibles?
Innovación ¿Cómo afectarán al resultado final las tecnologías y enfoques
9.
únicos a este proyecto?
Escala ¿Cómo impactará en el rendimiento del proyecto la superación de
10.
la experiencia pasada en volumen y alcance?

 Análisis de supuestos: Un supuesto es una incertidumbre que se considera

como cierta para seguir gestionando el proyecto. Son un tipo de riesgos que
caen fuera de la zona de control del equipo de gestión. No es posible
anticiparse al problema que ocurriría si dejasen de ser ciertos: habría que
escalarlo al patrocinador o a la dirección. Es muy recomendable revisar
periódicamente el registro de supuestos, verificar que todavía siguen vigentes,
que no hay otros nuevos y que son consistentes entre sí.
 Técnicas de diagramación:
 Diagramas causa-efecto (espina de pescado, Ishikawa): Permiten conectar
gráficamente el problema con sus causas principales y secundarias.
Causa Causa
principal principal
Causa de nivel 1
Causa de
nivel 2
Efecto
Causa Causa Causa

principal principal principal
 Flujos de procesos o de sistema: Muestran cómo se relacionan entre sí los

diferentes elementos de un sistema, y el mecanismo de causalidad.
 Diagramas de influencia: Muestran gráficamente las influencias causales, la

cronología de eventos y otras relaciones entre las variables y los
resultados.

 Análisis DAFO: Esta técnica examina el proyecto desde cada uno de los
aspectos DAFO (debilidades y amenazas, fortalezas y oportunidades -SWOT
en inglés). Permite aumentar el espectro de riesgos identificados. Primero se
identifican las fortalezas y debilidades de la organización, centrándose ya sea
en el proyecto, en la organización o en el negocio en general. Después se
identifica cualquier oportunidad para el proyecto con origen en las fortalezas de
la organización, y cualquier amenaza con origen en las debilidades de la
organización. El análisis también examina el grado en el que las fortalezas de
la organización contrarrestan las amenazas, e identifica las oportunidades que
pueden servir para superar las debilidades.
 Juicio de expertos: Los expertos con la experiencia adecuada, adquirida en

proyectos o áreas de negocio similares, pueden identificar los riesgos
directamente. El director del proyecto debe identificar a dichos expertos e
invitarlos a considerar todos los aspectos del proyecto, y a sugerir los posibles
riesgos basándose en sus experiencias previas y en sus áreas de
especialización. En este proceso se deben tener en cuenta los sesgos de los
expertos.
6.2.3. SALIDAS
11.2.3.1 Registro de Riesgos: Este documento aparece por primera vez en este
proceso y se refina sucesivamente hasta el fin del proyecto. En este momento,
contiene la lista de riesgos identificados con sus respuestas potenciales.

Ejercicio 3. Considerando el proyecto del caso del Aeropuerto de Denver:
Identifique el riesgo del “retraso del software ABHS” siguiendo la estructura

descrita para la reunión de tormenta de ideas ilustrada en el proceso 11.2.
Solución:
1. Resultado catastrófico: El aeropuerto abre sus puertas 15 meses más tarde

de lo previsto, ocasionando unas pérdidas de 500$ millones a la ciudad de
Denver.
2. Escenario: El día de la apertura todo está terminado salvo un componente

crítico.
3. Causa: Se retrasa la entrega del software de gestión de equipajes.
4. Riesgo: Retraso ABHS.
Ejercicio 4. Considerando en el proyecto del caso práctico desarrollado en el

anexo I, el proyecto traducir un libro:
1. Describa el perfil de riesgo de la organización ejecutora y de los principales

interesados.
2. Describa los activos de procesos de la organización relacionados con la

gestión de riesgos.
3. Conteste las 9 preguntas del test de madurez en gestión de riesgos descrito

en el proceso 11.1.
4. Construya 3 ó más frases que empiecen “Yo no tengo derecho a creer

que…”
5. Construya 3 ó más frases que empiecen “Si ocurre esto y estaría fuera de mi
zona de control, y por tanto tomo el supuesto de que…”
6. Describa al menos 3 incertidumbres positivas, u oportunidades.
7. ¿Qué juicio experto le parece necesario para identificar los riesgos de su

proyecto?

Solución:
1. El perfil de riesgo de la organización ejecutora (PMI Madrid) es conservador

(de aversión al riesgo). Esto también es cierto para el resto de las
organizaciones implicadas (PMI Barcelona, PMI Valencia, PMI Buenos Aires,
Editorial VHP) como para los interesados individuales (voluntarios, editor, autor,
presidentes de los capítulos y revisores externos).
2. Para este proyecto, PMI Madrid cuenta con un sistema de información de

gestión de proyectos denominado TALAIA Open PPM, que tiene un módulo
para gestionar los riesgos.
3. Test de madurez organizativa en gestión de riesgos. Para cada riesgo:
¿Hay un registro de riesgos publicado? ¿Contiene dicha lista los riesgos

causales más importantes, no sólo los pocos riesgos que todos tememos? ¿Es
1 No
visible para todos los que trabajan en el proyecto? ¿Hay suficientes riesgos en
la lista como para indicar un análisis cuidadoso de riesgos?
¿Hay un mecanismo continuo para descubrir nuevos riesgos? ¿Los
2 No
participantes se sienten seguros al declarar riesgos?
3 ¿Son algunos de los riesgos de la lista potencialmente fatales? N/A
4 ¿Se cuantifica cada riesgo en probabilidad e impacto de coste y tiempo? N/A
¿Cada riesgo tiene asociado un factor desencadenante, o disparador? ¿Se N/A
5
monitorizan?
6 ¿Hay una persona responsable de gestión de riesgos? N/A
7 ¿Hay trabajos en la EDT que puede que no tengan que hacerse? N/A
8 ¿Tiene el esfuerzo total una estimación y un objetivo, y son diferentes? N/A
¿Hay una probabilidad significativa de terminar bastante antes de la fecha N/A
9
estimada?
4. Identificar riesgos: No tengo derecho a creer que…
 … el texto traducido no resulte poco legible o inconsistente con la Guía del

PMBOK® v5.
 … no se pierda algún fichero almacenado en Google Drive.
 … los voluntarios dominen la herramienta Microsoft Word.
 … los voluntarios tengan buena disposición para usar las herramientas de
trabajo virtual.
5. Identificar supuestos: Este suceso estaría fuera de mi zona de control, por

tanto tomo el supuesto de que…
 … los capítulos del PMI llegan a un acuerdo contractual sobre los derechos de
explotación.
 ... los interesados respetan los derechos de copyright.

 ... los voluntarios del trabajan con buen desempeño durante el periodo, sin
causar baja.
 ... los voluntarios tienen buen conocimiento de la Guía del PMBOK® v5.
 ... los voluntarios tienen alto nivel de inglés.
6. Incertidumbres positivas, u oportunidades:
 La traducción se hace correctamente “a la primera” y se minimiza el esfuerzo

de revisión.
 Word permite automatizar el seguimiento del progreso en las fases de
traducción y revisión.
 El libro traducido acaba convirtiéndose en un best-seller en la comunidad del
PMI.
 Los voluntarios logran una notoriedad personal inesperada en PMI gracias a
este proyecto.
7. Expertos para identificar riesgos:
 Autores y editor del libro original.

 Miembros del equipo de traducción.
 Profesionales de servicios de traducción de inglés a español (traductores,
revisores, etc.)
 Docentes de cursos para preparar el examen PMP®.
 Voluntarios del PMI en el proyecto de verificación de la traducción de la Guía
del PMBOK® v5.
 Miembros del PMI españoles y latinoamericanos.
6.3. Realizar el Análisis Cualitativo de Riesgos
Realizar el Análisis Cualitativo de Riesgos es el proceso de priorizar riesgos

para análisis o acción posterior, evaluando y combinando la probabilidad de ocurrencia
e impacto de dichos riesgos. El beneficio clave de este proceso es que permite a los
directores de proyecto reducir el nivel de incertidumbre y concentrarse en los riesgos
de alta prioridad.

Este proceso evalúa la prioridad de los riesgos identificados a través de la

probabilidad relativa de ocurrencia, del impacto correspondiente sobre los objetivos del
proyecto si los riesgos llegaran a presentarse, así como de otros factores, tales como
el plazo de respuesta y la tolerancia al riesgo por parte de la organización, asociados
con las restricciones del proyecto en términos de costes, cronograma, alcance y
calidad. Realizar el Análisis Cualitativo de Riesgos es por lo general un medio rápido y
económico de establecer prioridades para Planificar la Respuesta a los Riesgos y
sienta las bases para Realizar el Análisis Cuantitativo de Riesgos, si fuera necesario.
El proceso Realizar el Análisis Cualitativo de Riesgos se lleva a cabo de manera
regular a lo largo del ciclo de vida del proyecto, tal como se define en el plan de
gestión de riesgos del proyecto. Este proceso puede conducir al proceso 11.4 Realizar
el Análisis Cuantitativo de Riesgos o directamente al proceso 11.5 Planificar la
Respuesta a los Riesgos.
6.3.1. ENTRADAS
 Plan de gestión de riesgos.

 Línea base del alcance: Analizando la línea base del alcance se puede saber el
grado de complejidad o innovación del proyecto. A más complejidad o
innovación, mayor incertidumbre.
 Registro de riesgos: Contiene la lista de riesgos.
 Factores Ambientales de la Empresa: Algunos factores ambientales influyen en
este proceso:
 Estudios del sector sobre gestión de riesgos en proyectos similares.
 Bases de datos de riesgos del sector o de la organización.


en este proceso:
 Archivos de proyectos anteriores (los problemas de ayer son los riesgos de
hoy).
 Evaluación de probabilidad e impacto de los riesgos: Con ayuda de expertos o

entrevistando a ciertos interesados, para cada riesgo, conforme a las escalas
definidas en el plan de gestión de riesgos, se evalúa su probabilidad de
ocurrencia (p.ej.: 0.1, 0.3, 0.5, 0.7, 0.9) y su impacto (p.ej.: de 1 a 5) sobre un
objetivo del proyecto, tal como el cronograma, el coste, la calidad o el
desempeño. También se registran los detalles explicativos. Se evalúan tanto
las amenazas como las oportunidades. Los riesgos de baja calificación de
probabilidad e impacto se incluirán en el registro de riesgos como parte de una
lista de observación (watch list) para su seguimiento futuro.
 Matriz Probabilidad-Impacto: Por lo general, la evaluación de la importancia de
cada riesgo y de su prioridad de atención se efectúa utilizando una tabla de
búsqueda o una matriz de probabilidad e impacto. Dicha matriz especifica las
combinaciones de probabilidad e impacto que llevan a calificar los riesgos con
una prioridad baja, moderada o alta. Dependiendo de las preferencias de la
organización, se pueden utilizar términos descriptivos (alto, moderado, bajo),
colores semafóricos (rojo, ámbar, verde) o valores numéricos. Conviene
manejar matrices separadas para amenazas y oportunidades.
 Evaluación de la calidad de los datos: Un riesgo no se podrá priorizar

adecuadamente si sus datos no se comprenden, o bien no son exactos, fiables
o íntegros.
 Categorización de riesgos: Los riesgos que pertenezcan a la misma categoría
se priorizarán de forma más eficiente y consistente.
 Evaluación de la urgencia de los riesgos: Los riesgos pueden ordenarse por la
fecha de su posible ocurrencia, lo que permitiría dar más prioridad a los más
próximos en el tiempo, vigilando sus disparadores o desencadenantes
(triggers) y activando oportunamente las actividades de mitigación.

 Juicio de expertos: La contribución de expertos, a través de entrevistas o

talleres facilitados, es muy conveniente para puntuar la importancia relativa de
los riesgos. No obstante, hay que tener en cuenta el sesgo que puedan
introducir los expertos.
6.3.3. SALIDAS
 Actualizaciones a los documentos del proyecto: Algunos documentos que

pueden irse actualizando a medida que se dispone de nueva información
cualitativa de riesgos:
 Registro de riesgos: evaluaciones de probabilidad e impacto para cada
riesgo, clasificación y calificación de riesgos, información de la urgencia o
categorización de los riesgos, así como una lista de observación para los
riesgos de baja probabilidad o que requieren análisis adicional.
 Registro de supuestos: Se revisa para dar cabida a nueva información. Los
supuestos se pueden incorporar en el enunciado del alcance del proyecto o
en un registro de supuestos independiente.
6.4. Realizar el Análisis Cuantitativo de Riesgos
Realizar el Análisis Cuantitativo de Riesgos es el proceso de analizar

numéricamente el efecto de los riesgos identificados sobre los objetivos generales del
proyecto (tales como el cronograma, el coste, la calidad, el desempeño, etc.) El
beneficio clave de este proceso es que genera información cuantitativa sobre los
riesgos para apoyar la toma de decisiones a fin de reducir la incertidumbre del
proyecto.

Después de realizar un análisis cuantitativo de riesgos, el equipo de dirección

del proyecto podría decir, por ejemplo: “Terminar antes de enero es imposible, la fecha
más probable para entregar un producto aceptable es el 1 de marzo, pero incluso esta
fecha no es muy creíble (30%), hay que esperar al 15 de abril si se quiere publicar una
fecha límite con el 50% de confianza, pero si se quiere probabilidad de retraso
virtualmente nula, hay que publicar como fecha de fin de proyecto el 1 de julio”. Este
análisis cuantitativo se puede representar gráficamente con la distribución de
probabilidad (la probabilidad de terminar antes de una fecha es el área bajo la curva a
la izquierda de esa fecha):
Por otra parte, si se representa el efecto sobre el presupuesto (véase la gráfica

de la derecha), podríamos saber que es imposible terminar con menos de 900.000€, y
que deberíamos reservar 200.000€ para contingencias con el fin de tener una
confianza del 50%.
Estas gráficas se denominan diagramas de incertidumbre, o diagramas de

riesgo. Son muy útiles cuando se trata de medir en rango de incertidumbre que
provocan los riesgos. ¿Cómo se obtienen?

Antes de proseguir me gustaría proponerles un ejercicio que no tiene que ver

con gestión de proyectos, pero sí con el fundamento matemático que se utilizará
después. El ejercicio consiste en estimar el número pi.
 Como es sabido, el área de un

cuadrante circular de radio 1 es ¶/4.
Si pudiéramos generar 10.000
puntos aleatorios de coordenadas (x,
y) variando x e y aleatoriamente
entre 0-1, la probabilidad de que
cayesen dentro del cuadrante
circular sería exactamente de ¶/4.
 Con la herramienta Microsoft Excel
podemos generar esos 10.000
puntos aleatorios y contabilizar
aquellos que caen dentro del
cuadrante circular: aquellos que
cumplan la condición x2+y2<1.
 Si dividimos este número entre 10.000 y multiplicamos por 4, obtenemos un
valor sorprendentemente aproximado a 3,1415.
Esta capacidad computacional que tienen los ordenadores personales hoy día
para generar números aleatorios, es la base de la técnica de modelado denominada
“análisis de Monte Carlo”, que sirve para obtener un diagrama de riesgo agregado a
partir de otros riesgos causales.
Generalmente, entre los activos de procesos de una organización con alta

madurez en gestión de riesgos, se encuentra información histórica tabulada sobre
proyectos previos similares. Cada riesgo puede tener una gráfica de probabilidad
indicando su efecto sobre el objetivo de plazo o coste. A partir de estas gráficas, si
nuestro proyecto se ve afectado por uno o varios de estos riesgos, puede usarse la
técnica de Monte Carlo para elaborar la gráfica del riesgo agregado.

Por ejemplo, imaginemos que en nuestro proyecto hemos de considerar estos

cuatro riesgos:
1. Errores de Planificación: Un proyecto se puede retrasar por estimar

incorrectamente duraciones y costes, supuestos, dependencias, etc. La
empresa puede tener un registro mostrando que los proyectos, en media, se
retrasan un 18% por esta razón, y como máximo un 55%.
2. Inflación de Requisitos: Un proyecto se puede retrasar porque durante el
mismo aparecen más requisitos, o estos cambian más de lo esperado. La
3. Rotación del Personal: Las bajas inesperadas de miembros del equipo y el
impacto de las sustituciones pueden ocasionar importantes retrasos. La
4. Productividad: El desempeño esperado puede no ser el previsto. Puede
haberse estimado una tasa de productividad de 30 puntos función por persona
y mes, o una velocidad de 50 puntos por iteración, etc., pero la productividad
media al final del proyecto puede haber sido inferior, produciendo el
consiguiente retraso. La empresa puede tener un registro mostrando que los
proyectos, en media, no se retrasan por esta razón, pero puede ocasionar un
retraso máximo del 15% y también ocurre que a veces el desempeño es mejor
de lo esperado, llegando a ser hasta un 13% mejor.
Si nuestro proyecto se ve afectado por los tres primeros riesgos (es un equipo
con mucha experiencia, no será un problema la productividad), deberíamos “mezclar”
estas tres gráficas en una sola. Para eso sirve la técnica de Monte Carlo. Se generan
aleatoriamente una gran cantidad de números aleatorios entre 0-1, y para cada uno se
halla la correspondiente abscisa en estas gráficas, y luego se calcula la abscisa
resultante en la nueva gráfica. Por ejemplo, si se genera el número aleatorio 0.8, los
percentiles 80% de las tres gráficas de arriba serían, respectivamente 1.32, 1.10 y
1.06. Multiplicando estos números obtendríamos el percentil 80% de la nueva gráfica:
1.53. Así sucesivamente, simulando 500 tiradas, podríamos construir esta gráfica
referida al proyecto.

Es decir, si el proyecto tuviera un plazo estimado de 2 años, considerando

estos tres riesgos elementales, podríamos decir que hay una probabilidad del 50% de
completarlo antes de 31 meses (24*1.31=31) y es seguro que se termina antes de 42
meses (24*1.77=42). Podemos saber que la confianza de terminar antes de 26 meses
es tan solo del 30% (el percentil 30% de la nueva curva es 1.11).
Muchas herramientas de gestión de proyectos utilizan el método de simulación

de Monte Carlo para estimar la duración esperada o el coste esperado de un proyecto,
a partir de la duración esperada o el coste de las actividades elementales: A partir de
la distribución de probabilidad de las actividades del camino crítico, y las de los costes
de todas las actividades, pueden construir la distribución de probabilidad del proyecto
de tiempo y costes.
En resumen, el proceso 11.4 Realizar el Análisis Cuantitativo de Riesgos

consiste básicamente en expresar numéricamente la incertidumbre. Es útil
principalmente a la hora de comunicar el impacto de ciertos riesgos a la dirección. No
menos importante es que aporta "nuevo conocimiento" sobre los riesgos agregados a
partir de los riesgos elementales: Por ejemplo, en una lista de 12 riesgos, cada uno
con una probabilidad insignificante del 10%, la probabilidad de que alguno de ellos se
materialice ya es de un 72%, lo cual ya no es insignificante.
6.4.1. ENTRADAS
 Plan de gestión de riesgos: Explica cómo ha de desarrollarse este proceso,

cuándo y con qué recursos. Proporciona guías, métodos y herramientas para
su utilización en el análisis cuantitativo de riesgos.
 Plan de gestión de costes: Proporciona guías para el establecimiento y la
gestión de las reservas de riesgos. Por ejemplo, en el plan de gestión de
costes puede haberse definido la fórmula para calcular la reserva para
contingencias restando el percentil 50 al percentil 0.

En la gráfica, el percentil 50 es 1.100.000 € (es decir, el proyecto terminará con

un coste inferior a 1.100.000€ con una probabilidad del 50%), el percentil 0 es
900.000€ (es decir, si no ocurre ningún riesgo, lo cual es prácticamente
imposible, el proyecto terminaría con un coste de 900.000€, resultado de sumar
los costes de las actividades sin margen de seguridad). La línea base de costes
tendría un presupuesto a la conclusión de 1.100.000€ (incluyendo una reserva
que el proyecto terminaría sin sobrecoste con una probabilidad del 50%.
 Plan de gestión del cronograma: Proporciona guías para el establecimiento y la

gestión de las reservas de riesgos. Es decir, el plan de gestión del cronograma
podría establecer la regla para calcular las reservas (de tiempo) para
contingencias del proyecto.
Por ejemplo, siguiendo el mismo razonamiento anterior, según la gráfica, la

línea base del cronograma tendría una duración del proyecto hasta el 15 de
abril (i
marzo) para declarar con una probabilidad del 50% que el proyecto terminará
en plazo.
 Registro de riesgos: Se utiliza como punto de referencia para llevar a cabo el
análisis cuantitativo de riesgos. Contiene la lista de riesgos priorizada. La
priorización cuantitativa tiene un coste, por lo que no suele hacerse sobre todos
los riesgos, sino sobre los más importantes. El plan de gestión de riesgos
determina los criterios de selección.
 Estudios del sector sobre gestión de riesgos en proyectos similares.
 Bases de datos de riesgos del sector o de la organización.
en este proceso:
 Archivos de proyectos anteriores (los problemas de ayer son los riesgos de
hoy).

 Técnicas de recopilación y representación de datos:
Entrevistas: Para cuantificar riesgos sobre las estimaciones de plazos y costes, en

estas entrevistas se recopila información sobre los escenarios optimistas,
pesimistas y más probables de los eventos de riesgo.
Distribuciones de probabilidad: Estas gráficas sirven para representar la

probabilidad relativa de los resultados posibles. La probabilidad absoluta (e.g. de
entregar antes de una fecha) es el porcentaje de área bajo la curva a la izquierda.
La gráfica del ejemplo permite representar gráficamente la siguiente información:
 Terminar antes de enero es imposible.

 La fecha más probable para entregar un producto aceptable es el 31 de
marzo, pero incluso esta fecha no es muy creíble (la confianza es sólo del
30%, o lo que es lo mismo, el área bajo la curva a la izquierda del 31 de
marzo es el 30% del área total).
 Hay que decir 15 de abril si se quiere publicar una fecha límite con el 50%
de confianza.
 Si se quiere probabilidad de retraso virtualmente nula, hay que publicar
como fecha de fin de proyecto el 1 de junio.
 Técnicas de análisis cuantitativo de riesgo y técnicas de modelado:
 Análisis de sensibilidad: Ayuda a determinar qué riesgos tienen el mayor

impacto posible sobre el proyecto. Este método examina la medida en que
la incertidumbre de cada elemento del proyecto afecta al objetivo que está
siendo examinado, cuando todos los demás elementos inciertos se
mantienen en sus valores de base. Una representación típica del análisis
de sensibilidad es el diagrama de tornado, que es útil para ilustrar el rango
de incertidumbre que producen los riesgos individuales sobre un objetivo
del proyecto. Por ejemplo, en la figura puede observarse que el riesgo 1 es
el más sensible, porque podría producir una desviación de coste de entre
+18.000€ y -9.000€, mientras que el riesgo 6 es el menos sensible, ya que
podría producir una desviación de coste de entre +500€ y -500€.

 Análisis del Valor Monetario Esperado (Expected Monetary Value –EMV-):

El análisis del valor monetario esperado es un concepto estadístico que
calcula el resultado promedio cuando el futuro incluye escenarios que
pueden ocurrir o no con distintos grados de incertidumbre. El valor
monetario esperado de las oportunidades generalmente se expresará con
valores positivos, mientras que el de los riesgos será negativo. El valor
monetario esperado se calcula multiplicando el valor de cada posible
resultado por su probabilidad de ocurrencia, y sumando los resultados. Este
tipo de análisis se usa comúnmente en el análisis mediante árbol de
decisiones.
 Análisis mediante árbol de decisiones: El análisis mediante árbol de

decisiones se estructura usando un diagrama de árbol de decisiones, que
describe una situación que se está considerando, y las implicaciones de
cada una de las opciones disponibles y los posibles escenarios. Al resolver
el árbol de decisiones se obtiene el valor monetario esperado. El ejemplo
representado en la figura sirve para tomar la decisión de reformar las
instalaciones actuales de un negocio (EMV=46 k€), antes que trasladarlo a
un nuevo edificio (EMV=36 k€).

En estos diagramas, las decisiones se representan como las ramas que

salen de un cuadrado, las diferentes posibilidades se representan como las
ramas que salen de un círculo (la suma de las probabilidades debe ser
100%) y finalmente los nodos finales, o resultados, se representan como
triángulos. En el ejemplo puede observarse que la decisión de reformar
tiene dos posibilidades: 1) que haya una gran demanda, con lo que el
resultado sería de 70 k€ = 120 k€ de beneficios – 50 k€ de la inversión; y 2)
pequeña demanda, con un el resultado de 10 k€ = 60 k€– 50 k€. Para
obtener el EMV antes de un círculo, se suman los valores de las ramas
posibles, cada una multiplicando el resultado por su probabilidad (el EMV
de Reformar es 60%*70 k€ + 40%*10 k€ = 46 k€). Para obtener el EMV
antes de un cuadrado, se elige el valor mayor (el EMV de Comprar o
Reformar es 46 k€, que es mayor que 36 k€).
Simulación y modelado: La técnica más conocida es la técnica de

simulación de Monte Carlo, que permite combinar las distribuciones de
probabilidad de varios riesgos en una sola gráfica, a partir de miles de
simulaciones aleatorias.
 Juicio de expertos: La contribución de expertos es muy conveniente para
puntuar el grado de exposición económica de los riesgos.
6.4.3. SALIDAS
 Actualizaciones a los documentos del proyecto: El registro de riesgos se

actualiza con el análisis probabilístico del proyecto, la probabilidad de alcanzar
los objetivos de coste y tiempo, la lista priorizada de riesgos cuantificados y las
tendencias en los resultados del análisis cuantitativo de riesgos.
Ejercicio 5. La tabla muestra los riesgos sobre duraciones y costes para las
actividades de un determinado proyecto. Evaluar el rango de resultados posibles del
proyecto mediante la técnica de simulación de Monte Carlo.

Solución:
 Utilizando herramientas que permiten ejecutar simulaciones de Monte Carlo,

podríamos obtener gráficas de probabilidad acumulada para el tiempo y el
coste del proyecto:
Ejercicio 6. Si en su empresa no disponen de herramientas para ejecutar

simulaciones de Monte Carlo, ¿cómo podrían estimar el rango de resultados posibles?
Solución:
El proyecto durará 1382 ± 85 días (confianza 68%), o lo que es lo mismo: entre

1296 y 1467 días, con una confianza del 68%. La duración optimista es de 1020 días
y la duración pesimista es de 1900 días:
 Utilizando las fórmulas para estimación por tres valores, pueden calcularse las
duraciones esperadas para cada actividad.
 La duración mínima del proyecto (1020 días) se obtiene sumando las
estimaciones optimistas de las actividades críticas.
 La duración máxima del proyecto (1900 días) se obtiene sumando las
estimaciones pesimistas de las actividades críticas.
 Las duración esperada del proyecto (1382 días) es la suma de las duraciones
esperadas de las actividades críticas (nótese que hay una fórmula para PERT
o distribución beta y hay otra fórmula para distribución triangular).
 La varianza de la suma es la suma de las varianzas. La raíz cuadrada es la
desviación típica (sigma) para el proyecto. Así se obtiene que sigma = 85 días.
Podemos decir que hay una confianza del 68% entre ± 85 días respecto a la
duración esperada.

Por lo que se refiere a los costes, el proyecto costará 208.783€ ± 9.247€

(confianza 68%), o lo que es lo mismo: entre 199.536€ y 218.030€, con una confianza
del 68%. El presupuesto a la conclusión mínimo es de 164.000€ y como mucho podría
ascender hasta 279.700€:
 Utilizando las fórmulas para estimación por tres valores, pueden calcularse los
costes esperados para cada actividad.
 El coste mínimo del proyecto (164.000€) se obtiene sumando las estimaciones
optimistas de todas las actividades.
 El coste máximo del proyecto (279.700€) se obtiene sumando las estimaciones
pesimistas de todas las actividades.
 El coste esperado del proyecto (208.783€) es la suma de los costes esperados
de todas las actividades (nótese que hay una fórmula para PERT o distribución
beta y hay otra fórmula para distribución triangular).
 La varianza de la suma es la suma de las varianzas. La raíz cuadrada es la
desviación típica (sigma) para el proyecto. Así se obtiene que sigma = 9.247€.
Podemos decir que hay una confianza del 68% entre ± 9.247€. Respecto al
coste esperado.
6.5. Planificar la Respuesta a los Riesgos
Planificar la Respuesta a los Riesgos es el proceso de desarrollar opciones y

acciones para mejorar las oportunidades y reducir las amenazas que afecten a los
objetivos del proyecto. El beneficio clave de este proceso es que aborda los riesgos en
función de su prioridad, introduciendo recursos y actividades en el presupuesto, el
cronograma y el plan para la dirección del proyecto, según las necesidades.

El objetivo de este proceso es decidir estrategias y acciones concretas para

minimizar los efectos negativos y maximizar los positivos. Para cada riesgo hay que
asignar a la persona responsable de controlarlo (el propietario del riesgo). Al elaborar
una respuesta a un riesgo, se recomienda contestar las siguientes preguntas:
 ¿Será eficaz?
 ¿Será oportuna?
 ¿Cómo afectará a los objetivos de coste, plazo y calidad?
 ¿Será proporcionada?
 ¿Creará otro riesgo secundario?
 ¿Dejará un riesgo residual?
Un riesgo residual es aquel que prevalece después de que se han

implementado las respuestas al riesgo original. Un riesgo secundario es un riesgo
nuevo que aparece como consecuencia de implementar una respuesta al riesgo
original.
6.5.1. ENTRADAS
 Plan de gestión de riesgos: Explica cómo ha de desarrollarse este proceso,

quién, cuándo y con qué recursos. Define los umbrales para considerar un
riesgo como alto, medio o bajo.
 Registro de riesgos: Contiene la lista de riesgos priorizada cualitativa y a veces
cuantitativamente: causa, probabilidad, impacto, prioridad, urgencia,
disparador, propietario, EMV, etc.

 Estrategias para riesgos negativos (amenazas):

 Aceptar: Consiste en asumir el posible efecto negativo, sin actuar antes de
su materialización. La aceptación puede ser activa si se asigna una reserva
de contingencia para minimizar el impacto tras la ocurrencia, o bien pasiva
en caso contrario.
 Evitar: Evitar que ocurra. Suele implicar no hacer el proyecto o la parte que
supone ese riesgo.
 Mitigar: Realizar actividades previas a la ocurrencia para atenuar el posible
impacto.
 Transferir: Trasladar el impacto negativo de una amenaza, junto con la
propiedad de la respuesta, a un tercero.
 Estrategias para riesgos positivos (oportunidades):
 Aceptar: Consiste en asumir el posible efecto positivo, sin actuar antes de
su materialización.
 Explotar: Cuando la organización ejecutante desea asegurarse que la
oportunidad se haga realidad.
 Mejorar: Aumentar el “tamaño” de la oportunidad, aumentando la
probabilidad y/o los impactos positivos, e identificando y maximizando las
fuerzas impulsoras clave.
 Compartir: Compartir la propiedad con un tercero que está mejor
capacitado para capturar la oportunidad para beneficio del proyecto.
 Estrategias de respuesta a contingencias: Las amenazas que se hayan
decidido contener, muchas veces requieren planes de contingencia o planes de
reserva. Estos planes incluyen los eventos desencadenantes (disparadores, o
triggers) que ponen en marcha los planes.
 Juicio de expertos: La contribución de expertos es conveniente para idear la
respuesta a los riesgos.
6.5.3. SALIDAS
 Actualización al plan para la dirección del proyecto: Las estrategias de

respuesta a los riesgos, una vez acordadas, deben retroalimentarse a los
procesos apropiados de otras áreas de conocimiento, incluidos el plan de
gestión del cronograma, el plan de gestión de costes, el plan de gestión de
calidad, el plan de gestión de las adquisiciones, el plan de gestión de recursos
humanos y las tres línea base (alcance, cronograma y costes).

 Actualizaciones de documentos del proyecto:

 Registro de riesgos: El equipo de dirección del proyecto debe asegurarse
de que cada riesgo contiene la información definida en el plan de gestión de
riesgos, que suele ser: nombre del riesgo, prioridad, probabilidad, impacto,
EMV, estrategias de respuesta, acciones de respuesta, planes de
contingencia, disparador, responsable, presupuesto, reservas de
contingencia, riesgos residuales, etc. También puede haber nuevas
entradas para los riesgos secundarios.
 Otros documentos susceptibles de actualización: Registro de supuestos,
documentación técnica, solicitudes de cambios.
Ejercicio 7. Utilizando los datos del ejercicio 6, si en su empresa se calcula la

reserva de tiempo para contingencias con el percentil 20 y el cálculo de la reserva de
coste para contingencias con el percentil 50, ¿cuál sería la reserva para contingencias
de tiempo y coste?
Solución:
 Reserva de tiempo para contingencias: Percentil 20 – Percentil 0 = 1296 –

1020 = 276 días.
 Reserva de coste para contingencias: Percentil 50 – Percentil 0 = 218.783€ –
164.000€ = 44.783€.
Ejercicio 8. Le piden estimar las reservas de contingencia para su proyecto,

cuyo presupuesto es de 1 M€. El equipo de dirección del proyecto ha analizado
cuantitativamente 5 riesgos y después ha decidido aplicar las siguientes respuestas:
evitar (avoid) el primero; aceptar activamente o contener (contain) el segundo y el
quinto; mitigar (mitigate) el tercero y aceptar pasivamente o asumir (evade) el cuarto.
En la tabla también se muestra el cálculo del valor monetario esperado para cada
riesgo. Calcule las reservas para contingencia.
Probabilidad Impacto Riesgo Respuesta

Riesgo 1 10% 25.000 € 2.500 € evitar
Riesgo 2 15% 50.000 € 7.500 € contener
13.500 € 10.800 mitigar
Riesgo 3 80%
€
32.500 € 19.500 asumir
Riesgo 4 60%
€
40.000 € 12.000 contener
Riesgo 5 30%
€

Solución
 No se tienen en cuenta los que se evitan ni los que se mitigan. Los que se
mitigan supondrán un coste cierto durante el proyecto, solo deberíamos
contemplar el EMV de los riesgos residuales, pero el enunciado no lo indica. Sí
se consideran los que se contienen y los que se asumen.
 Puede calcularse la reserva como el EMV (Expected Monetary Value) de estos
riesgos = 39 k€.
Probabilidad Impacto Riesgo Respuesta

Riesgo 2 15% 50.000 € 7.500 € contener
Riesgo 4 60% 32.500 € 19.500 € asumir
Riesgo 5 30% 40.000 € 12.000 € contener
122.500 € 39.000 €
Ejercicio 9. Considere que en caso anterior se realizó un análisis cuantitativo

con la técnica de simulación de Monte Carlo, obteniendo la siguiente información
sobre el impacto de los riesgos 2, 4 y 5 en el objetivo de coste: El percentil 90 es
1.040.000€ El percentil 50 es 1.020.000€ y el percentil 0 es 1.000.000 €. Tomando el
mismo criterio que en el ejercicio 8 ¿cuál sería la reserva para contingencias?
Solución:
 Percentil 50 – Percentil 0 = 1.020.000€ – 1.000.000€ = 20 k€. Es decir: hay

una probabilidad del 50% de que el proyecto termine con un presupuesto entre
1.000.000€ y 1.020.000€, por lo que la reserva para contingencias debe ser de
20.000 €.
Ejercicio 10. Usted es director de proyectos en la empresa A para el desarrollo

de un sistema de banca online para su banco local, por el que su empresa cobrará 20
M€. Sin embargo, el banco tiene mucho interés en implementar rápidamente este
sistema y también ha contratado a la empresa B. Usted debe terminar el sistema en 6
meses para asegurar que adelantan a la empresa B. Calcule el valor monetario
esperado en este momento:

 Usted tiene una estimación de costes de 2,5 M€.

 Perderá 10 M€ si no puede entregar el producto en 6 meses.
 Si lo termina antes, ganará 25 M€ adicionales.
 El Director de Riesgos de su empresa realiza un análisis y le comunica que
tiene una probabilidad del 30% de que el banco cambie los requisitos y un 70%
de probabilidad de que el proyecto se complete a tiempo o antes del plazo.
 Su empresa ha realizado proyectos similares en el pasado y sobre la base de
estas experiencias, usted sabe que hay un 30% de probabilidades de que sus
costes se incrementen 2,5 M€.
Solución:
A través del árbol de decisiones, puede deducirse que hay 4 resultados

posibles. Considerando todas las opciones, el proyecto tiene, en este momento, un
valor monetario esperado de 31,25 M€, resultado de sumar los EMV de las distintas
opciones posibles.
 En el caso mejor no habrá cambio de requisitos ni sobrecoste, con lo que se

ganarían 42,5 M€ = 20 de ingresos – 2,5 de costes + 25 de incentivos. La
probabilidad de esta opción es del 49%, resultado de multiplicar la probabilidad
de terminar en plazo (70%) y sin sobrecoste (1-30%). El EMV de esta opción
es: 42,5 * 49% =20,8 M€.
 Si no hay retraso y hay sobrecoste, el resultado sería de 40 M€. La
de terminar en plazo (70%) y con sobrecoste (30%). El EMV de esta opción es:
40 * 21% =8,4 M€.
 Si hay retraso y no hay sobrecoste, el resultado sería de 7,5 M€. La
de no terminar en plazo (1-70%) y sin sobrecoste (1-30%). El EMV de esta
opción es: 7,5 * 21% =1,6 M€.

 En el caso peor habrá retraso y sobrecoste, con lo que el resultado sería de 5

M€. La probabilidad de esta opción es del 9%, resultado de multiplicar la
probabilidad de no terminar en plazo (1-70%) y con sobrecoste (30%). El EMV
de esta opción es: 5 * 9% =0,45 M€.
Ejercicio 11. El director financiero de su empresa le pide el presupuesto de su

proyecto. La estimación de los costes de las actividades asciende a 1 M€ (incluyendo
unos riesgos que ha decidido mitigar con unas actividades un coste estimado en 50
k€). La reserva para contingencias asciende a 100 k€ y la reserva de gestión es de 50
k€. ¿Cuál es el presupuesto que hay que trasladar al Director Financiero? ¿Qué
presupuesto utilizaría en este momento para elaborar la línea base de costes?
Solución:
En la figura puede observarse que el presupuesto del proyecto es de 1.150 k€

y la línea base de costes tiene un presupuesto de 1.100 k€.
7. CONTROL DE CAMBIOS Y ANALISIS DE IMPACTO
Sistema de Control Integrado de Cambios
Los proyectos sufren cambios. Sin embargo, tan importante como procesar los
cambios, es la actividad permanente del director de proyectos de asegurar que todo el
trabajo va según lo planificado y en caso contrario, comparar lo real con lo esperado y
proponer acciones correctoras para reducir las desviaciones. Los procesos
relacionados con “controlar los cambios” se dedican a medir el desempeño del
proyecto y a proponer cambios que serán implementados en 4.3 Dirigir y Gestionar el
Trabajo del Proyecto. Los cambios no aprobados no deberían implementarse.

Con el fin de que los cambios del proyecto se gestionen de manera integrada,
suele elaborarse un plan de gestión de cambios, que habitualmente especifica el ciclo
de vida de gestión de los cambios incluyendo las siguientes directrices:
Primero, las solicitudes de cambios han de recibirse en un determinado formato

documentado.
El equipo de dirección del proyecto debe analizar la petición, evaluar su

impacto y proponer soluciones alternativas.
Sobre la base de este análisis, se pronunciará el órgano de decisión

correspondiente, que puede ser el Comité de Control de Cambios, el equipo de
dirección del Proyecto o el Director del Proyecto:
• Si el cambio se rechaza, hay que justificar por qué, e informar a los

interesados.
• Si se aprueba, hay que documentar la solicitud del cambio aprobada, con el

objeto de que pueda ser implementada apropiadamente a través del proceso
4.3 Dirigir y Gestionar el Trabajo del Proyecto y habrá que actualizar algunos
documentos del proyecto e informar a los interesados.
Los cambios urgentes, después de implementarse, deben documentarse y

seguir también el sistema de control integrado de cambios.
Por lo que se refiere a los cambios, la Guía del PMBOK® distingue tres tipos de
cambios:
 Acción correctiva: Una actividad que procura volver a alinear el

desempeño del trabajo del proyecto con el plan para la dirección del
proyecto.
 Acción preventiva: Una actividad que asegura que el desempeño futuro
del trabajo del proyecto esté alineado con el plan para la dirección del
proyecto.
 Reparación de defectos: Una actividad para modificar un producto o
componente de producto no conforme.
Sistema de Gestión de la Configuración
La Guía del PMBOK® define el sistema de gestión de la configuración como el

conjunto de procedimientos formalmente documentados que se utilizan para
implementar la dirección y supervisión técnica y administrativa para:
 Identificar y documentar las características funcionales y físicas de un

producto, resultado, servicio o componente.
 Controlar cualquier cambio a dichas características.
 Registrar e informar cada cambio y su estado de implantación.

 Brindar apoyo a la auditoría de productos, resultados o componentes para

verificar que cumplen con los requisitos. Incluye la documentación, los
sistemas de rastreo, y los niveles necesarios de aprobación, definidos para
autorizar y controlar los cambios.
Por ejemplo, en el caso práctico desarrollado en el anexo, el proyecto de

traducir un libro, el sistema de configuración era la organización de los ficheros y
carpetas en un directorio compartido de Google Drive. Se creó una estructura de
carpetas y nomenclatura para los documentos de gestión y otra para los documentos
del trabajo. El sistema de gestión de configuración de este proyecto incluía, entre otros
puntos, las reglas básicas para: Nombrar los ficheros, gestionar sus versiones, cómo
comparar documentos y procesar cambios propuestos, cómo relacionar los originales
en inglés con sus equivalentes traducidos al español, los ficheros de texto con los
ficheros de imágenes, cómo relacionar documentos y subdocumentos, el
procedimiento para compilar un capítulo a partir de sus partes, pasarlo a PDF, trazar el
impacto de un cambio en un subdocumento, contabilizar palabras, cambios pendientes
y aprobados, etc.
7.1. Dirigir y Gestionar el Trabajo del Proyecto
Dirigir y Gestionar el Trabajo del Proyecto es el proceso de liderar y llevar a

cabo el trabajo definido en el plan para la dirección del proyecto, así como de
implementar los cambios aprobados, con el fin de alcanzar los objetivos del proyecto.

El director del proyecto, junto con el equipo de dirección del proyecto, es el

responsable de dirigir la ejecución de las actividades planificadas en el proyecto, así
como de gestionar las distintas interfaces, técnicas y organizativas, del proyecto. El
objetivo de los procesos de ejecución es hacer que las cosas se hagan, sin juzgar el
desempeño. El resultado de la ejecución a veces se materializa en forma de
entregables. Estos entregables producidos, así como los hechos relevantes de la
ejecución (datos de desempeño del trabajo), las comunicaciones , los incidentes, las
solicitudes de cambios, etc., son entradas para los procesos de control, que permitirán
determinar el trabajo completado, pronosticar si se alcanzarán los objetivos, aprobar
cambios para corregir la gestión, etc.
El equipo de dirección del proyecto realiza, entre otras, las siguientes

actividades de gestión de la ejecución del proyecto:
 Adquirir los recursos, desarrollar y gestionar al equipo del proyecto.

 Hacer que se ejecuten las actividades planificadas, los cambios aprobados y
tratar los riesgos.
 Emitir solicitudes de cambios, analizando el impacto y proponiendo soluciones
para facilitar su control.
 Asegurar la calidad.
 Implementar las actividades aprobadas de mejora de procesos.
 Gestionar las comunicaciones y la participación de los interesados.
 Dar soporte a los procesos de contratación de proveedores.
 Recopilar y documentar las lecciones aprendidas.

7.1.1. ENTRADAS
Solicitudes de cambios aprobadas: Las solicitudes de cambios aprobadas

son una salida del proceso 4.5 Realizar el Control Integrado de Cambios e incluyen las
solicitudes revisadas y aprobadas para su implementación por un comité de control de
cambios. Una solicitud de cambio aprobada puede consistir en una acción correctiva,
una acción preventiva o una reparación de defectos. Las solicitudes de cambios
aprobadas se planifican e implementan por parte del equipo del proyecto y pueden
tener repercusión sobre cualquier área del proyecto o del plan para la dirección del
proyecto. Las solicitudes de cambios aprobadas pueden asimismo modificar las
políticas, el plan para la dirección del proyecto, los procedimientos, los costes o los
presupuestos, así como forzar la revisión de los cronogramas.
Factores Ambientales de la Empresa: Incluyen, entre otros:
• Cultura de la organización, compañía o cliente y estructura de las

organizaciones ejecutora o patrocinadora.
• Infraestructura (p.ej., instalaciones existentes y bienes de capital).
• Administración del personal (p.ej., guías de contratación y despido, revisión

del desempeño de los empleados y registros de capacitación).
• Tolerancia al riesgo de los interesados, como por ejemplo el porcentaje de

sobrecoste permitido.
• El sistema de información para la dirección de proyectos (p.ej., un conjunto de

herramientas automáticas, tales como una herramienta de software para definir
cronogramas, un sistema de gestión de la configuración, un sistema de recopilación y
distribución de la información o interfaces web con otros sistemas automáticos en
línea).
Activos de los Procesos de la Organización: Incluyen, entre otros:
• Guías e instrucciones de trabajo estandarizadas.
• Requisitos de comunicación que definen los medios de comunicación

permitidos y el tiempo de conservación de los registros, así como requisitos de
seguridad.
• Procedimientos para la gestión de incidentes y defectos que definen los

controles para incidentes y defectos, la identificación y la solución de los mismos, así
como el seguimiento de los elementos de acción.

• Base de datos para la medición de procesos, que se utiliza para recopilar y

tener a disposición los datos de mediciones de procesos y productos.
• Archivos de proyectos anteriores (p.ej., líneas base del alcance, de costes, del
cronograma y de medición del desempeño, calendario del proyecto, diagramas de red
del cronograma del proyecto, registros de riesgos, acciones de respuesta planificadas,
impacto de los riesgos y lecciones aprendidas documentadas).
• Bases de datos sobre la gestión de incidentes y defectos, que contienen el

estado histórico de los mismos, información de control, resolución de los incidentes y
defectos, y resultados de las acciones emprendidas.
Juicio de expertos: El juicio de los expertos permite utilizar los conocimientos

y experiencias previas en beneficio del proyecto. Estos conocimientos y experiencias
los pueden aportar tanto el director del proyecto, como el equipo de dirección del
proyecto; además, también puede obtenerse información muy valiosa en otras
unidades de la organización, en los propios interesados en el proyecto, en
asociaciones profesionales, etc.
Sistema de Información para la Dirección de Proyectos (PMIS): El sistema

de información para la dirección de proyectos, que forma parte de los factores
ambientales, proporciona acceso a herramientas tales como una herramienta para
definir cronogramas, un sistema de autorización de trabajos, un sistema de gestión de
la configuración, un sistema de recopilación y distribución de la información o
interfaces a otros sistemas automáticos en línea. La automatización de la recopilación
y el informe de los indicadores clave de desempeño (KPIs) pueden formar parte de
este sistema. En la figura se ofrecen algunos ejemplos de herramientas software para
la gestión de proyectos, muy difundidas en la actualidad:

Reuniones: Las reuniones se utilizan para discutir y abordar los asuntos

pertinentes del proyecto durante la dirección y gestión del trabajo del proyecto. Los
asistentes a las reuniones pueden incluir al director del proyecto, al equipo del
proyecto y a los interesados adecuados, involucrados o afectados por los asuntos
tratados. Cada asistente debería tener un rol establecido, de modo que se asegure la
participación adecuada. Las reuniones deben prepararse con una agenda bien
definida, con un propósito, con un objetivo y con un marco temporal y deben ser
adecuadamente documentadas con actas de reunión y lista de acciones a realizar. Las
actas de reunión deben ser almacenadas como se indique en el plan para la dirección
del proyecto. Las reuniones son más eficaces cuando todos los participantes pueden
intervenir cara a cara en el mismo lugar. Se pueden realizar reuniones virtuales
usando herramientas de audio y/o videoconferencia, pero generalmente requieren una
preparación y una organización adicionales para conseguir la misma eficacia que la de
una reunión cara a cara. Suele haber reuniones de tres tipos (no deben mezclarse): 1)
De intercambio de información; 2) Tormenta de ideas, evaluación de opciones o
diseño y 3) De toma de decisiones.
7.1.3. SALIDAS
Entregables: Un entregable es cualquier producto, resultado o capacidad de

prestar un servicio, único y verificable, que debe producirse para terminar un proceso,
una fase o un proyecto. Los entregables son en general componentes tangibles que se
generan para cumplir con los objetivos del proyecto y que pueden incluir elementos del
plan para la dirección del proyecto.
Datos de desempeño del trabajo: Los datos de desempeño del trabajo son
las observaciones y mediciones brutas identificadas durante la ejecución de las
actividades para llevar a cabo el trabajo del proyecto. Los datos se consideran a
menudo como el nivel más bajo de detalle del que pueden extraer información otros
procesos. Los datos se recopilan a través de la ejecución de los trabajos y se pasan a
los procesos de control de cada una de las áreas de procesos para su posterior
análisis. Entre los ejemplos de datos de desempeño del trabajo se incluyen el trabajo
completado, los indicadores clave de desempeño, las medidas de desempeño técnico,
las fechas de comienzo y finalización de las actividades planificadas, el número de
solicitudes de cambios, el número de defectos, los costes reales, las duraciones
reales, etc.
Solicitudes de cambios: Una solicitud de cambio es una propuesta formal

para modificar cualquier documento, entregable o pedir un cambio a la línea base. Una
solicitud de cambio aprobada reemplazará el documento, el entregable o la
actualización de la línea base asociados y puede resultar en una actualización a otras
partes del plan para la dirección del proyecto.

Cuando se detectan problemas durante la ejecución del trabajo del proyecto, se

emiten solicitudes de cambios que pueden modificar las políticas o los procedimientos,
el alcance, el coste, el presupuesto, el cronograma o la calidad del proyecto. Otras
solicitudes de cambios incluyen las acciones preventivas o correctivas necesarias para
impedir un impacto negativo posterior en el proyecto. Las solicitudes de cambios
pueden ser directas o indirectas, originadas interna o externamente, opcionales u
obligatorias (ya sea por ley o por contrato), y pueden abarcar:
• Acción correctiva: Una actividad intencionada que procura realinear el

desempeño del trabajo del proyecto con el plan para la dirección del proyecto.
• Acción preventiva: Una actividad intencionada que asegura que el desempeño

futuro del trabajo del proyecto esté alineado con el plan para la dirección del
proyecto.
• Reparación de defectos: Una actividad intencionada para modificar un

producto o componente de producto no conforme.
• Actualizaciones: Cambios en los elementos formalmente controlados del

proyecto, como documentos, planes, etc., para reflejar ideas o contenidos que
se han modificado o añadido.
Actualizaciones al plan para la dirección del proyecto: Los planes

secundarios y las líneas base son elementos susceptibles de actualización.
Actualizaciones a los documentos del proyecto: Ejemplos de documentos

• La documentación de requisitos.
• El registro de incidentes,
• El registro de supuestos.
• El registro de riesgos.
• El registro de interesados.
7.2. Realizar el Control Integrado de Cambios
Realizar el Control Integrado de Cambios es el proceso de analizar todas las

solicitudes de cambios; aprobar y gestionar los cambios a los entregables, activos de
los procesos de la organización, documentos del proyecto y plan para la dirección del
proyecto; y comunicar las decisiones correspondientes.


actividades relacionadas con el control integrado de cambios del proyecto:
El plan para la dirección del proyecto, el enunciado del alcance del proyecto y
otros entregables se mantienen actualizados por medio de una gestión rigurosa y
continua de los cambios, ya sea rechazándolos o aprobándolos, de manera tal que se
asegure que sólo los cambios aprobados se incorporen a una línea base revisada.
Cualquier interesado involucrado en el proyecto puede solicitar cambios.

Aunque los cambios pueden iniciarse verbalmente, deben registrarse por escrito e
ingresarse al sistema de gestión de cambios y/o al sistema de gestión de la
configuración. Las solicitudes de cambios están sujetas a los procesos especificados
en los sistemas de control de cambios y de la configuración. Estos procesos de
solicitud de cambios pueden requerir información sobre los impactos estimados en el
tiempo y en el coste.
Cada una de las solicitudes de cambios documentadas debe ser aprobada o

rechazada por un responsable, generalmente el patrocinador o el director del proyecto.
Dicho responsable estará identificado en el plan para la dirección del proyecto o en los
procedimientos de la organización.
Comité de Control de Cambios
Si fuera necesario, el proceso 4.5 Realizar el Control Integrado de Cambios

incorporará un comité de control de cambios, que es un grupo formalmente constituido
responsable de revisar, evaluar, aprobar, retrasar o rechazar los cambios en el
proyecto, así como de registrar y comunicar dichas decisiones.

Las solicitudes de cambios aprobadas pueden requerir la revisión o

reelaboración de estimaciones de costes, secuencias de actividades, fechas
programadas, necesidades de recursos y análisis de alternativas de respuesta a los
riesgos.
Estos cambios pueden requerir ajustes al plan para la dirección del proyecto u
otros documentos del proyecto.
El nivel de control de cambios utilizado depende del área de aplicación, de la

complejidad del proyecto específico, de los requisitos del contrato, y del contexto y el
entorno en los que se ejecuta el proyecto.
Algunas solicitudes de cambios pueden requerir la aprobación del cliente o del

patrocinador tras la aprobación por el CCB, a no ser que aquéllos formen parte del
mismo.
Sistema de Gestión de la Configuración

actividades relacionadas con la gestión de la configuración del proyecto:
Identificación de la configuración: La identificación y selección de un

elemento de configuración proporciona la base para la que se define y verifica la
configuración del producto, con la que se etiquetan los productos y documentos, se
gestionan los cambios y se establece la responsabilidad.
Seguimiento del estado de la configuración: La información se registra y se

reporta con respecto a cuándo deben proporcionarse datos pertinentes acerca de un
elemento de configuración. Esta información incluye un listado de la identificación de la
configuración aprobada, el estado de los cambios propuestos a la configuración y el
estado de implementación de los cambios aprobados.
Verificación y auditoría de la configuración: La verificación y las auditorías

de la configuración aseguran que la composición de elementos de configuración de un
proyecto es correcta y que los cambios correspondientes se registran, se evalúan, se
aprueban, se revisan y se implementan correctamente. Esto asegura el cumplimiento
de los requisitos funcionales definidos en los documentos de configuración.

7.2.1. ENTRADAS
Plan para la dirección del proyecto.
Informes de desempeño del trabajo: Incluyen datos de disponibilidad de

recursos, cronograma y costes, informes de gestión del valor ganado (EVM) y gráficas
de seguimiento de trabajo realizado y pendiente de realizar.
Solicitudes de Cambios: Todos los procesos de monitorización y control y

muchos de los procesos de ejecución generan solicitudes de cambios como salidas.
Todas las solicitudes de cambios se centralizan finalmente en este proceso para su
procesamiento integrado.
Factores Ambientales de la Empresa: El sistema de información para la

dirección de proyectos.
• Procedimientos de control de cambios.
• Procedimientos para aprobar y emitir autorizaciones de cambios.
• Base de datos para la medición de procesos...
• Documentos del proyecto (p.ej., líneas base del alcance, de costes y del
cronograma, calendario del proyecto, diagramas de red del cronograma del
proyecto, registros de riesgos, acciones planificadas de respuesta e impacto
establecido del riesgo).
• Base de conocimiento de gestión de la configuración, que contiene las

versiones y líneas base de todos los estándares, políticas y procedimientos
oficiales de la organización, y cualquier otro documento del proyecto.
Juicio de expertos: Además del juicio de los expertos del equipo de dirección
del proyecto, se puede solicitar a los interesados que aporten su experiencia y que
formen parte del comité de control de cambios.
Reuniones: En este caso particular, las reuniones se suelen denominar

reuniones de control de cambios. Cuando el proyecto lo requiere se designa un comité
de control de cambios responsable de reunirse y revisar las solicitudes de cambios, y
de aprobar, rechazar o tomar otras decisiones en relación con dichos cambios. El
comité de control de cambios también puede revisar las actividades de gestión de la
configuración.

Los roles y responsabilidades de estos comités están claramente definidos y

son acordados por los interesados adecuados, así como documentados en el plan de
gestión de cambios. Las decisiones del comité de control de cambios se documentan y
se comunican a los interesados para su información y para la realización de acciones
de seguimiento.
Herramientas de control de cambios: Con objeto de facilitar la gestión de la

configuración y la gestión de cambios se pueden utilizar herramientas manuales o
automatizadas.
7.2.3. SALIDAS
Solicitudes de cambios aprobadas: Las solicitudes de cambios son

procesadas por el director del proyecto, el comité de control de cambios o un miembro
designado del equipo, de acuerdo con el sistema de control de cambios. Las
solicitudes de cambios aprobadas se implementarán mediante el proceso 4.3 Dirigir y
Gestionar el Trabajo del Proyecto. El estado de todas las solicitudes de cambios,
aprobadas o no, se actualizará en el registro de cambios como parte de las
actualizaciones a los documentos del proyecto.
Registro de cambios: Un registro de cambios se utiliza para documentar los

cambios que se realizan durante el proyecto. Dichos cambios y su impacto en el
proyecto en términos de tiempo, costes y riesgos deben ser comunicados a los
interesados adecuados. Las solicitudes de cambios rechazadas también se incluyen
en el registro de cambios.
Actualizaciones al plan para la dirección del proyecto.
Actualizaciones a los documentos del proyecto.
8. CONTROL DEL CRONOGRAMA Y LOS COSTES
Según la Guía del PMBOK®, una línea base es una versión aprobada de un
producto de trabajo que sólo puede cambiarse mediante procedimientos formales de
control de cambios y que se usa como base de comparación. En otras palabras,
podríamos decir que la expresión cuantitativa de lo que debería ocurrir se denomina
línea base. En todo proyecto hay 3 líneas base. Línea base de alcance: ¿vamos
haciendo lo que había que hacer? Línea base del cronograma: ¿vamos en fecha,
retrasados, adelantados? Línea base de costes: ¿vamos en coste, con sobrecoste, por
debajo de coste?

Hay muchas formas correctas ya inventadas para medir cuantitativamente el

desempeño de un proyecto. Sin embargo, el análisis cuantitativo no se improvisa bien.
Cuando nos piden una explicación puntual sobre los retrasos, por ejemplo, siempre
podremos preparar una hoja de cálculo o una presentación con nuestro análisis. El
problema es que si tenemos que hacer esto cada semana, no nos quedará tiempo
para hacer otra cosa, y no gestionaremos el proyecto con eficacia. En la actualidad,
hay herramientas muy eficaces para planificar lo que debería ocurrir y contrastarlo con
lo que está ocurriendo realmente. Si estas herramientas se alimentan con regularidad,
analizar desviaciones no cuesta nada. Para realizar el seguimiento, es eficaz usar las
herramientas que ya existen.
El subgrupo de “Controlar las Líneas Base” incluye cuatro procesos, que

pueden considerarse como los procesos más “técnicos” que debe dominar el director
de proyectos. Son las habilidades más hard y menos soft, si queremos decirlo así.
Afortunadamente, aquí hay herramientas y técnicas que han demostrado su
efectividad y hay un camino de aprendizaje muy transitado. Por desgracia para quien
no domina esas técnicas, las evidencias de poca profesionalidad suelen ser objetivas y
evidentes.
En la siguiente figura se muestran los procesos dedicados a controlar las líneas

base de alcance, el cronograma y costes:

5.5 Validar el Alcance: Consiste en formalizar la aceptación de los entregables

del proyecto que se hayan completado. El equipo ya ha verificado los entregables
generados en ejecución en el proceso 8.3 Controlar la Calidad. El siguiente paso es
hacerlo llegar con la configuración adecuada al cliente (o a ciertos usuarios
representativos del cliente o la organización solicitante) con el fin de que estos
entregables sean validados mediante su inspección correspondiente. Aunque la
decisión está en el tejado del cliente, no por ello el equipo de gestión tiene que
desentenderse. Al contrario: es muy importante que si los entregables son correctos, la
validación se produzca, si es posible poco a poco, a medida que se va entregando
parcialmente, de tal modo que cuando la lista completa de entregables está aceptada,
el equipo de dirección ya se puede plantear el cierre del proyecto. Como el cierre de
un proyecto es una de las actividades más importantes y distintivas en gestión de
proyectos, gestionar para que se den las condiciones de cierre no es menos
importante. El proceso 5.5 Validar el Alcance, muchas veces se complica porque los
clientes son reacios a aceptar. Comunicar eficazmente con estos clientes, resolver
incidentes y conflictos, escalar los problemas a otros niveles de autoridad, etc. suelen
ser actividades que implican mucha carga de gestión.
5.6 Controlar el Alcance: Consiste en monitorizar el estado del proyecto y del

alcance del producto, y gestionar los cambios a la línea base del alcance. Para medir
el alcance se indican los porcentajes completados sobre cada cuenta de control.
6.7 Controlar el Cronograma: Consiste en dar seguimiento del estado de las

actividades del proyecto para actualizar el avance del mismo y gestionar los cambios a
la línea base del cronograma a fin de cumplir el plan. Para medir el cronograma se
puede representar el porcentaje completado de cada actividad y comparar las fechas
de comienzo y fin reales con las planificadas.
7.4 Controlar los Costes: Consiste en monitorizar el estado del proyecto para
actualizar los costes del mismo y gestionar posibles cambios a la línea base de costes.
Para medir el desempeño de costes, se puede comparar el presupuesto que
realmente se ha ganado (conseguido, completado, producido) contra el presupuesto
previsto a la fecha y contra lo incurrido a la fecha.
Gestión del Valor Ganado
En el proceso 7.4 Controlar los Costes es importante seguir un método

estandarizado para calcular las desviaciones y los pronósticos. Cuando el patrocinador
nos pregunta ¿cómo va mi proyecto? generalmente le interesa si se cumplirá el
objetivo de coste, es decir, si hay sobrecoste en este momento y cuál será el
sobrecoste cuando el proyecto termine. Generalmente, entre los activos de procesos
de nuestra empresa tendremos los métodos de cálculo, y estamos obligados a
utilizarlos como es debido. El método estandarizado para determinar cuantitativamente
el desempeño de costes de un proyecto es el método de Gestión del Valor Ganado
(Earned Value Management –EVM).

EVM es un método utilizado para medir el progreso de ejecución de un

proyecto de forma objetiva que se ha convertido en un estándar de facto. Fue
introducido por el Departamento de Defensa de EE.UU. para controlar de forma
eficiente sus proyectos realizados internamente o contratados. Posteriormente se
extendió a toda la Administración americana para adquisiciones, control y seguimiento
de proyectos. Desde 1998 es estándar ANSI 748. EVM Combina tres aspectos de
capital importancia en la ejecución de un proyecto: alcance (cumplimiento del trabajo
planificado), costes (si se gasta más o menos de lo planificado) y plazo (si el proyecto
se adelanta o se retrasa):
La planificación detallada del proyecto indica lo que se va a hacer y en qué

fechas, así como cuánto se ha pensado que costará (tanto en esfuerzo de personal
como en materiales). Esto da lugar a una serie de datos que se conoce como Valor
Planificado (Planned Value –PV-), que no es otra cosa que la proyección temporal del
presupuesto, o línea base de costes.
Por otra parte, se determina en cada momento el grado de terminación de las

actividades planificadas al comienzo del proyecto. Esto da lugar a otra serie de datos
que se conoce como Valor Ganado (Earned Value –EV-), que indica el coste
conseguido, ganado o producido hasta la fecha.
Y finalmente, se conoce en cada momento el valor de los Costes Reales

(Actual Cost –AC-), o incurrido hasta la fecha.
Por ejemplo, sea un proyecto de plazo 6 meses, con 4 cuentas de control

principales A-D. En el plan de gestión de costes se decidió utilizar las horas de
esfuerzo como unidad de coste (en lugar de €). En la reunión de seguimiento del 30 de
abril, del presupuesto a la conclusión de 6000 horas (1500, 1500, 2000 y 1000,
respectivamente), según se había planificado en la línea base de costes, se debería
haber consumido 4000 horas (1500, 1500, 1000 y 0). Los datos de desempeño del
trabajo dicen que se han gastado 3700 horas (1200, 1000, 1500 y 0) y se sabe el
porcentaje completado de cada cuenta de control (100%, 33%, 75% y 0%). Utilizando
el método EVM, puede ofrecerse la siguiente información sobre el desempeño actual y
esperado:

Antes de usar EVM, es recomendable familiarizarse con la terminología

utilizada en este estándar (hay algunas siglas que es preciso aprender):
Las fórmulas básicas de EVM sirven para calcular las desviaciones hasta la
fecha y los pronósticos:

A continuación se ofrece un cuadro con más fórmulas y su interpretación en el

ejemplo anterior:
Aplicando las fórmulas al ejemplo anterior puede verse cómo se han obtenido
los resultados:

Veamos a continuación otro ejemplo: Un proyecto tiene un presupuesto a la

conclusión de 150k€. En la fecha de evaluación del estado se tiene PV=40k€,
AC=48k€, EV=32k€.
La desviación del coste (Cost Variance) se calcula CV=EV-AC=32-48=-16k€

(es negativa, hay un sobrecoste de 16k€).
La desviación del cronograma (Schedule Variance) se calcula SV=EV-PV=32-

40=-8k€ (es negativa, hay retraso). A la finalización del proyecto se cumplirá que
SV=0.
El índice de desempeño de costes (Cost Performance Index) se calcula

CPI=EV/AC=0,67 (es menor que 1, hay sobrecoste: 1€ invertido produce 0,67€).
El índice de desempeño del cronograma (Schedule Performance Index) se

calcula SPI=EV/PV=0,8 (es menor que 1, hay retraso, avanzamos a un ritmo del 80%
de lo previsto). A la finalización del proyecto, SPI=1.
En cuanto al cálculo de los pronósticos, hay que saber que la Estimación del
Coste a la Conclusión (EAC, Estimate At Completion) es siempre igual al Coste Real
(AC, Actual Cost) más la Estimación hasta la Conclusión (ETC, Estimate To
Complete). Es decir, EAC = AC + ETC. Pero hay 5 formas distintas de calcular ETC:

1) Si los supuestos iniciales no eran correctos: ETC = Estimación detallada

ascendente (bottom up) del trabajo restante.
2) Si las desviaciones actuales no son típicas, se debe realizar una proyección

basada en el presupuesto: ETC = BAC – EV
Si se espera que las desviaciones actuales se mantengan, hay 3 formas para

calcular ETC:
• 3) Proyección basada en el desempeño de costes: ETC = (BAC – EV) / CPI
• 4) Proyección basada en el desempeño de costes y cronograma: ETC = (BAC

– EV) / (CPI * SPI)
• 5) Proyección basada en el desempeño proporcionado de costes y

cronograma: ETC = (BAC – EV) / (0.8*CPI + 0.2*SPI)
En el ejemplo anterior, dado que supuestos iniciales no eran correctos, se

realizó una estimación detallada del trabajo hasta la conclusión ETC=142k€, lo que
permitió estimar EAC=48+142=190k€, lo que supondría una desviación a la conclusión
VAC=150-190=-40k€ (negativa, hay un sobrecoste estimado a la conclusión de 40k€).
Otro indicador importante del desempeño es el Índice de Desempeño del

Trabajo por Completar (TCPI): El ratio TCPI (To Complete Performance Index), se
calcula como trabajo pendiente según el presupuesto o financiación restante. Es decir,
sirve para determinar cuánto trabajo debe conseguirse por cada euro financiado.
Hay 2 formas de calcular el TCPI:
Si se toma como tope de financiación el presupuesto a la finalización (BAC):

TCPI1 = (BAC–EV) / (BAC–AC)
Si se toma como tope de financiación el coste estimado a la finalización (EAC):

TCPI2 = (BAC–EV) / (EAC–AC)

Por último, antes de concluir esta introducción del estándar EVM, es necesario
explicar dos puntos necesarios desde un punto de vista práctico:
No es presentable decir que la desviación del cronograma es de menos ocho

mil euros: si el interlocutor no está versado en EVM no entenderá que expresemos una
desviación temporal en euros. Para solucionar esto, en la segunda versión del
estándar se ha introducido el concepto del plazo ganado.
No es practicable, para un proyecto de tamaño medio, mantener los datos EVM

en una hoja de cálculo, para eso están las herramientas de gestión de proyectos.
Veremos cómo puede hacerse el control de costes en Microsoft Project, aplicando el
estándar EVM.
Earned schedule (ES), que puede traducirse como "plazo ganado", es una
extensión del estándar EVM desarrollada por Walter Lipke en su famoso artículo
"Schedule is Different”. Tradicionalmente, EVM mide las desviaciones del cronograma
no en unidades de tiempo, sino en unidades monetarias o de coste. A este problema
de comunicación se une otro problema aún mayor, relativo a que los indicadores SV y
SPI no se comportan bien al final del proyecto, precisamente cuando la preocupación
sobre los retrasos es mayor.

Para corregir estos problemas, la teoría del plazo ganado representa SV y SPI
en dos ámbitos separados: coste y tiempo. Se usa la nomenclatura SV (€) and SPI (€)
para referirse al coste; y SV (t) y SPI (t) para referirse al tiempo. Una gran ventaja del
método es que no hace falta recopilar nuevos datos, solo hay que aplicar nuevas
fórmulas para desviaciones y pronósticos. Por definición, el plazo ganado es el
momento en el que el dato actual de EV estaba planificado que ocurriera en la línea
base de costes. En el ejemplo de la figura, se puede calcular SV (t)=6–10= -4 meses,
o lo que es lo mismo: podemos asegurar que el proyecto va retrasado 4 meses. Con
estos mismos datos, habría que decir que la desviación del cronograma SV (€) es de
menos 1 millón de dólares, lo cual muy poca gente entendería. Por otra parte, se
demuestra que el indicador SPI (t)=0,6 será más significativo y se comportará mejor
que el indicador SPI (€)=0,8.
Veamos cómo se calcula ES y SV (t) con un sencillo ejemplo:
Supongamos que la fecha del estado del proyecto es el día 35 desde su

arranque. En este momento el valor ganado es 23.220€. Para proyectar este valor a la
curva PV, podemos aplicar semejanzas en los dos triángulos que se forman en el
segmento 20-25 días, donde sabemos que estará ES porque EV está entre
PV=23.560€ (valor planificado a los 25 días) y PV=19.480€ (valor planificado a los 20
días).
Aplicando estas semejanzas, sabemos que (23560–19480)/ (25-20)= (23220–

19480)/∆. Despejando queda ∆=4,58. Así pues: ES=20+4,58=24,58 días y SV
(t)=24,58–35=-10,42 días. Es decir, el retraso acumulado a la fecha es de 10,42 días.
Como puede observarse, las tres variables principales para calcular las
fórmulas de EVM son PV, AC y EV. Estas variables (y el resto de variables
dependientes obtenidas de las fórmulas) están disponibles en la mayoría de los
paquetes de Software de Gestión de Proyectos (por ejemplo, en Microsoft Project
pueden mostrarse informes con los valores EVM). Algunos productos mantienen las
denominaciones antiguas:

PV: Planned Value BCWS: Budget Cost of Work Scheduled (Coste

(Valor Planificado) Presupuestado del Trabajo Planificado)
EV: Earned Value BCWP: Budget Cost of Work Performed (Coste
(Valor Ganado) Presupuestado del Trabajo Realizado)
AC: Actual Cost (Coste ACWP: Actual Cost of Work Performed (Coste Real del
Real) Trabajo Realizado)
PV: Planned Value (Valor Planificado) BCWS: Budget Cost of Work

Scheduled (Coste Presupuestado del Trabajo Planificado)
EV: Earned Value (Valor Ganado) BCWP: Budget Cost of Work Performed
(Coste Presupuestado del Trabajo Realizado)
AC: Actual Cost (Coste Real) ACWP: Actual Cost of Work Performed
(Coste Real del Trabajo Realizado)
Gestión del Valor Ganado con Microsoft Project
Es importante elegir bien la herramienta para los cálculos EVM y registrar la

información. Muchos directores de proyectos usan Microsoft Excel® y acaban
frustrados cuando deben registrar mucha información sobre costes incurridos por los
distintos recursos. Cuando se animan a usar Microsoft Project® también hay
frustración porque muchas veces esta herramienta no se usa de forma apropiada.
Yo descubrí una forma rápida para introducir a los directores de proyectos en el

uso de EVM con Microsoft Project®, a partir del famoso ejercicio de “La Valla”, de Rita
Mulcahy.
Ejercicio 1. Imagine que su proyecto consiste en hacer una valla de 4 lados.

Cada lado lleva 1 día de trabajo de un operario, por 200€. Los lados se construyen
secuencialmente. Comienza el trabajo el día 12/09/2011. Usted presupuestó 800€. Al
final del día 3 (14/09/2011) ha completado el lado 1 (coste 200€) y el lado 2 (coste
275€). El lado 3 está completado al 50% (coste 200€). ¿Cuánto pagará finalmente?
Si el operario mantiene su ritmo de trabajo, el presupuesto a la finalización

ascenderá a 1080€. Este resultado puede calcularse fácilmente aplicando las fórmulas
de EVM: EAC = BAC/CPI; BAC=800; CPI = EV/AC = 500/675 = 0,74; EAC= 800/0,74 =
1080.

Usando Microsoft Project®, se puede obtener la solución en 4 pasos:
1) En primer lugar, usamos la vista Gantt Chart para introducir la información

de planificación (hay que fijar el comienzo del proyecto el día 12/9/2011):
2) Después entramos la tarifa del operario igual a 25€/h (200 €/día):
3) A continuación, grabamos la línea base (con lo que se graba toda la

información de planificación) y después introducimos la información sobre el trabajo
real. El trabajo real para el lado 2 fueron 11 horas (25*11=275€). El trabajo para el
lado 3 ha de ser replanificado porque solo se ha completado el 50% (hacen falta 2 días
para completarlo):

4) Finalmente, fijamos Status Date 3 días después del inicio (14/9/2011) y por
ultimo obtenemos el informe EVM en la vista Task Sheet tabla Earned Value:
En el Gantt de seguimiento podemos ver el progreso:
En el menú Report > Visual Reports > Earned Value over Time Report,
podemos obtener la gráfica EVM para los días transcurridos desde el comienzo:
Algunas anotaciones finales:
La unidad de gestión elemental de coste en Microsoft Project es las horas de

esfuerzo por recurso, por tarea y por unidad de tiempo. En las tablas de uso de
recursos o uso de tareas podemos controlar esto:

El campo Work significa las horas planificadas por recurso y tarea. Debe
actualizarse continuamente reflejando la última información del proyecto. Cambiar
Work significa replanificar: ¿Cuántas horas quedan? ¿Cuándo? La planificación por
defecto de las tareas es orientada al esfuerzo: El motor de planificación trata de
mantener constante el número de horas de esfuerzo.
El campo Cost se calcula: Work * Standard Rate. El campo Actual Work es

entrada de datos. El campo Actual Cost se calcula: Actual Work * Standard Rate
Al grabar la línea base, se actualizan a lo largo del tiempo las variables

Baseline Cost (= Cost) y Baseline Work (= Work). La curva PV es la variable Baseline
Cost a lo largo del tiempo.
Al nivel de tarea:
• PV = Baseline Cost hasta Status Date.
• AC = Actual Cost hasta Status Date.
• EV = (Actual Work / Work) * Baseline Cost = % Work Complete * Baseline Cost.
• Cost y Actual Cost se calculan con la tarifa estándar (que puede cambiar).
• Baseline Cost se calcula con la tarifa estándar original.
Sobre la forma de calcular EV, tengo que decir que todas la versiones que yo
he utilizado hasta la versión 2013 calculan EV de una forma que a mí me parece un
error de concepto, ya que el porcentaje completado se calcula como la fracción de
tiempo consumida, no la fracción de trabajo completado. En el pantallazo de la figura
tienen un ejemplo en la herramienta demostrando este comportamiento que espero
que se corrija en versiones futuras:

La actividad dura 2 días. El recurso asignado tiene una tarifa de 10€/h

(presupuesto=160€). El recurso ha trabajado 4 horas el primer día y está previsto que
trabaje 8 horas el segundo día. Debería calcular EV=4/12*160=53,33€ pero calcula
EV=1/2*160=80€.
Es decir, debería ser:
• EV = (Actual Work / Work) * Baseline Cost = % Work Complete * Baseline Cost
Pero tal y como está implementado hasta la versión 2013:
• EV = (Actual Duration / Duration) * Baseline Cost = % Complete * Baseline Cost
8.1. Controlar el Cronograma
Controlar el Cronograma es el proceso de monitorizar el estado de las

actividades del proyecto para actualizar el avance del mismo y gestionar los cambios
de la línea base del cronograma a fin de cumplir el plan. El beneficio clave de este
proceso es que proporciona los medios para detectar desviaciones con respecto al
plan y establecer acciones correctivas y preventivas para minimizar el riesgo.

El equipo de dirección del proyecto es responsable de terminar el proyecto en

el plazo asignado. Para alcanzar este objetivo debe medir continuamente el grado de
avance real y comparar contra lo planificado en la línea base del cronograma. Si las
desviaciones son significativas, se debe investigar las causas, proponer cambios que
implican tomar acciones correctivas o preventivas. A veces es necesario actualizar la
línea base del cronograma, lo cual es un cambio muy importante y debe hacerse de
forma consensuada con los interesados. Cualquier cambio relativo a la gestión del
tiempo del proyecto debe canalizarse a través del proceso 4.5 Realizar Control
Integrado de Cambios.
El control del cronograma del proyecto incluye:
• Determinar el estado actual del cronograma del proyecto.
• Influir en los factores que generan cambios en el cronograma.
• Determinar si el cronograma del proyecto ha cambiado.
• Gestionar los cambios reales conforme se producen.
8.1.1. ENTRADAS
Plan para la dirección del proyecto: El plan de gestión del cronograma

describe cómo se gestionará y controlará el cronograma del proyecto. La línea base
del cronograma se utiliza como base para comparar con los resultados reales a fin de
determinar si es necesario un cambio, una acción correctiva o una acción preventiva.

Cronograma del proyecto: Se refiere a la versión más reciente del

cronograma, con las pertinentes actualizaciones e información sobre las actividades
terminadas y las actividades comenzadas a la fecha de corte.
Datos de desempeño del trabajo: Consisten en los hechos relevantes sobre

el avance del proyecto, como por ejemplo qué actividades se han iniciado, su avance
(p.ej. duración real, duración pendiente y porcentaje físicamente completado), y qué
actividades se han completado.
Calendarios del proyecto: Permiten considerar diferentes periodos de trabajo

para algunas actividades a la hora de calcular los pronósticos del cronograma.
Datos del cronograma: Serán revisados y actualizados durante este proceso.
• Políticas, procedimientos y guías existentes, formales e informales,

relacionados con el control del cronograma.
• Herramientas de control del cronograma.
• Métodos de monitorización e información a utilizar.
Revisiones del desempeño: Permiten medir, comparar y analizar el

desempeño del cronograma, en aspectos como las fechas reales de inicio y
finalización, el porcentaje completado y la duración restante. Entre las diferentes
técnicas que se pueden utilizar, se cuentan:
• Análisis de tendencias: Analiza el desempeño del proyecto a lo largo del tiempo

para determinar si el desempeño está mejorando o se está deteriorando.
• Método del camino crítico: Monitoriza las tareas críticas (ya que cualquier
retraso se traslada al proyecto) y los caminos casi críticos (ya que son susceptibles de
convertirse en críticos si se retrasan algunas de sus tareas).

• Método de la cadena crítica: Se monitoriza especialmente el buffer de proyecto

para determinar si es adecuado implementar una acción correctiva.
• Gestión del valor ganado: Las medidas de variación del cronograma (SV) y el
índice de desempeño del cronograma (SPI) se utilizan para evaluar la magnitud de la
desviación con respecto a la línea base original del cronograma. Para proyectos que
no gestionan el valor ganado, se pueden comparar las fechas programadas con las
reales de comienzo y fin de las actividades, y así identificar desviaciones con respecto
a la línea base del cronograma.
Software de gestión de proyectos: Permite hacer un seguimiento de las

fechas planificadas en comparación con las fechas reales, informar sobre las
desviaciones en el avance con respecto a la línea base y pronosticar los efectos de los
cambios en el cronograma del proyecto.
Técnicas de optimización de recursos: Permiten planificar de los recursos

necesarios por las actividades teniendo en cuenta la disponibilidad de los recursos a lo
largo del tiempo.
Técnicas de modelado: El análisis de escenarios “Qué pasa si...” y las

técnicas de simulación permiten medir los impactos que podrían producir ciertas
causas probables de retrasos, analizando diferentes escenarios.
Adelantos y retrasos: El ajuste de adelantos y retrasos se utiliza durante el

análisis de la red con objeto de encontrar maneras de volver a alinear con el plan las
actividades retrasadas del proyecto.
Compresión del cronograma: Las técnicas de compresión del cronograma se

utilizan para encontrar maneras de volver a alinear las actividades retrasadas del
proyecto con el plan, mediante la ejecución rápida o la intensificación del cronograma
para el trabajo restante.
Herramienta de planificación: Los datos del cronograma se actualizan y

compilan en el modelo de programación para reflejar el avance real del proyecto y el
trabajo que queda pendiente. La herramienta de planificación y los datos de apoyo del
cronograma se utilizan en combinación con métodos manuales u otro software de
gestión de proyectos para realizar el análisis de la red del cronograma y generar un
cronograma actualizado del proyecto.
8.1.3. SALIDAS
Información de desempeño del trabajo: Los valores calculados de los

indicadores de desempeño en el tiempo, variación del cronograma (SV) e índice de
desempeño del cronograma (SPI), para los componentes de la EDT, y en particular los
paquetes de trabajo y las cuentas de control, se documentan y comunican a los
interesados.

Pronósticos del cronograma: Los pronósticos se actualizan y emiten

nuevamente sobre la base de la información de desempeño del trabajo suministrada a
medida que se desarrolla el proyecto. La información se basa en el desempeño
pasado del proyecto y en el desempeño previsto para el futuro e incluye indicadores
de valor ganado
Solicitudes de cambios: El análisis de la variación del cronograma, junto con

la revisión de los informes de avance, los resultados de las medidas de desempeño y
las modificaciones del alcance o del cronograma del proyecto, pueden dar como
resultado solicitudes de cambios de la línea base del cronograma y/o de otros
componentes del plan para la dirección del proyecto. Las acciones preventivas pueden
incluir cambios recomendados para eliminar o reducir la probabilidad de variaciones
negativas del cronograma.
Actualizaciones al plan para la dirección del proyecto: Elementos

• Línea base del cronograma: Los cambios de la línea base del cronograma se
incorporan como respuesta a las solicitudes de cambio aprobadas relacionadas con
cambios en el alcance, en los recursos de las actividades, en las estimaciones de las
duraciones, por aplicar técnicas de compresión del cronograma, etc.
• Plan de gestión del cronograma: Se puede actualizar para reflejar cualquier

cambio en la manera de gestionar el cronograma.
• Línea base de costes: Puede actualizarse para reflejar solicitudes de cambio

aprobadas o cambios originados por aplicar técnicas de compresión del cronograma.
Actualizaciones a los documentos del proyecto: Documentos susceptibles

de actualización:
• Datos del cronograma: Pueden desarrollarse nuevos diagramas de red para

reflejar las duraciones restantes aprobadas y las modificaciones aprobadas del
cronograma. En algunos casos, los retrasos en el cronograma del proyecto pueden ser
tan graves que se deberá desarrollar un nuevo cronograma objetivo.
• Cronograma del proyecto: Se generará un cronograma actualizado del proyecto

a partir del modelo de programación poblado con los datos actualizados del
cronograma.
• Registro de riesgos: El registro de riesgos y los planes de respuesta a los

riesgos son susceptibles de ser actualizados sobre la base de los riesgos que pueden
surgir al comprimir el cronograma.

Actualizaciones a los Activos de Procesos de la Organización: Entre los

activos susceptibles de actualización se cuentan:
• Las causas de las variaciones.
• Las acciones correctivas seleccionadas y su justificación.
• Otros tipos de lecciones aprendidas del control del cronograma del proyecto.
8.2. CONTROLAR LOS COSTES
Controlar los Costes es el proceso de monitorizar el estado del proyecto para

actualizar los costes del mismo y gestionar posibles cambios a la línea base de costes.
El beneficio clave de este proceso es que proporciona los medios para detectar
desviaciones con respecto al plan con objeto de tomar acciones correctivas y
minimizar el riesgo.
El equipo de dirección del proyecto es responsable de terminar el proyecto con

el presupuesto asignado. Para alcanzar este objetivo debe medir continuamente el
grado de avance real y comparar con lo planificado en la línea base de costes. Si las
desviaciones son significativas, se debe investigar las causas, proponer cambios que
implican tomar acciones correctivas o preventivas. A veces es necesario actualizar la
línea base de costes, lo cual implica frecuentemente modificar el presupuesto a la
finalización (BAC). Cualquier cambio relativo a la gestión de los costes debe
canalizarse a través del proceso 4.5 Realizar Control Integrado de Cambios.

El control de costes del proyecto incluye:
• Influir sobre los factores que producen cambios en la línea base de

costes autorizada.
• Asegurar que todas las solicitudes de cambio se lleven a cabo de

manera oportuna.
• Gestionar los cambios reales cuando y conforme suceden.
• Asegurar que los gastos no excedan la financiación autorizada por

periodo, por componente de la EDT, por actividad y para el proyecto en su totalidad.
• Monitorizar el desempeño de los costes para detectar y comprender las

variaciones con respecto a la línea base aprobada de costes.
• Monitorizar el desempeño del trabajo con relación a los gastos en los

que se ha incurrido.
• Evitar que se incluyan cambios no aprobados en los informes sobre

utilización de costes o de recursos.
• Informar a los interesados pertinentes acerca de todos los cambios

aprobados y costes asociados.
• Realizar las acciones necesarias para mantener los excesos de costes

previstos dentro de límites aceptables.
8.2.1. ENTRADAS
Plan de gestión del proyecto:
• Plan de gestión de costes. Describe la forma en que se gestionarán y

controlarán los costes del proyecto.
• Línea base de costes. Se compara con los resultados reales para

determinar si es necesario implementar un cambio, o una acción preventiva o
correctiva.
Requisitos de financiación del proyecto: En qué fechas se planificó que

estarían disponibles los fondos para financiar el proyecto. Estas fechas planificadas se
compararán con las reales. Los requisitos de financiación del proyecto incluyen gastos
proyectados y deudas anticipadas.

Datos de desempeño del trabajo: Grado de avance del proyecto (porcentaje

del trabajo completado, estimación del trabajo pendiente, costes incurridos,
autorizados, etc.) que sirve para comparar los costes reales con la línea base de
costes.
Activos de los Procesos de la Organización:
• Políticas, procedimientos y guías existentes, formales e informales,

relacionados con el control de costes.
• Herramientas para el control de los costes.
• Métodos de seguimiento e información que se utilizarán.
Gestión del Valor Ganado: Earned Value Management –EVM- (Gestión del
Valor Ganado) es una metodología que combina medidas de alcance, cronograma y
recursos para evaluar el desempeño y el avance del proyecto. Véase la descripción de
esta técnica en la introducción de este capítulo.
Pronósticos: Un pronóstico (forecast, en inglés) es una estimación o

predicción de condiciones y eventos futuros para el proyecto, basada en la información
y el conocimiento disponibles en el momento de realizar el pronóstico. La información
se basa en el desempeño pasado del proyecto y en el desempeño previsto para el
futuro, e incluye información que podría ejercer un impacto sobre el proyecto en el
futuro, tal como la estimación a la conclusión y la estimación hasta la conclusión. Para
saber cómo calcular pronósticos con la técnica EVM, véase la descripción de esta
técnica en la introducción de este capítulo.
Índice de Desempeño del Trabajo por Completar (TCPI): Es una medida del
desempeño del coste que se debe alcanzar con los recursos restantes a fin de cumplir
con un objetivo de gestión especificado. Se expresa como la tasa entre el coste para
culminar el trabajo pendiente y el presupuesto restante. Véase la descripción de esta
Mediciones del desempeño del trabajo: Para los paquetes de trabajo y las
cuentas de control, se realizan análisis sobre los indicadores de desviaciones CV, SV,
SV (t),VAC, etc., sobre los indicadores de desempeño CPI, SPI, SPI(t) y sobre los
datos de tendencia de EAC y fechas de finalización. Véase la descripción de esta

Software de gestión de proyectos: A menudo se utiliza el software de gestión

de proyectos para monitorizar las tres dimensiones de la gestión del valor ganado,
EVM (PV, EV y AC) para representar gráficamente tendencias y proyectar un rango de
resultados finales posibles para el proyecto.
Análisis de Reservas: Durante el control de los costes se utiliza el análisis de

reserva para hacer el seguimiento del estado de las reservas para contingencias y de
gestión, de cara a determinar si el proyecto todavía necesita estas reservas o si se han
de solicitar reservas adicionales. Las reservas para las contingencias no utilizadas se
podrían retirar del presupuesto del proyecto.
8.2.3. SALIDAS
Información de desempeño del trabajo: El resultado de los análisis sobre los

indicadores de desviaciones, desempeño y tendencias, se documentan y comunican a
los interesados.
Pronósticos de costes: El valor EAC debe documentarse y comunicarse a

los interesados.
Solicitudes de cambios: El análisis del desempeño de costes puede dar lugar

a una solicitud de cambio a la línea base de costes o de otros componentes del plan
de gestión del proyecto. Las solicitudes de cambio pueden incluir acciones preventivas
o correctivas y se procesan para su revisión y tratamiento por medio del proceso 4.5
Realizar el Control Integrado de Cambios.
Actualizaciones al plan para la dirección del proyecto:
• Línea base de costes: Los cambios de la línea base de costes se incorporan

en respuesta a las solicitudes de cambio aprobadas relacionadas con cambios en el
alcance del proyecto, en los recursos de las actividades o en las estimaciones de
costes. En algunos casos las variaciones del coste pueden ser tan importantes que se
hace necesario revisar la línea base de costes para proporcionar una base realista
para la medición del desempeño.

• Plan de gestión de costes: A menudo los interesados clave del proyecto

solicitan cambios al plan de gestión de costes, tales como cambios de los umbrales de
control o de los niveles especificados de exactitud, necesarios para gestionar los
costes del proyecto. Estos cambios se incorporan al plan de gestión de costes.
Actualizaciones a los documentos del proyecto: Entre los elementos

susceptibles de actualización se cuentan:
• Las estimaciones de costes.
• La base de las estimaciones.
Actualizaciones a los Activos de Procesos de la Organización: Entre los

activos susceptibles de actualización se cuentan:
• Las causas de las variaciones.
• Las acciones correctivas seleccionadas y las razones que las justifican.
• Las bases de datos financieras.
• Otros tipos de lecciones aprendidas procedentes del control de costes del

proyecto.
9. SEGUIMIENTO Y EVALUACIÓN DE RIESGOS
La peor imagen que puede proyectar un director de proyectos es cuando ocurre

algo así y él no lo tenía previsto, y se le ve nervioso, improvisando, alarmando a todos,
apretando el botón de “crisis”. Un director de proyectos quiere problemas, no quiere
sustos. Quiere ver los problemas venir, y tener preparada una respuesta que aplicar
cuando los problemas ocurren. No quiere improvisar.
El director de proyectos debe tener en cuenta que se le va a juzgar muy mal si

ocurre un problema importante que no tenía previsto. Para no llegar a dar nunca esta
mala imagen, lo que debe hacer es anticiparse, registrar los riesgos con detalle
mientras son meras abstracciones. Y sobre todo, debe comunicarlos bien. Todo el
grupo de interesados, especialmente el comité de gestión de riesgos, el comité de
seguimiento del proyecto, la PMO, etc., deben ser conscientes de las amenazas, de su
importancia y de la respuesta que se ha decidido aplicar en caso de que ocurran.

Un director de proyectos no expone las incertidumbres empleando un tono de

“queja”, o bien para asustar al grupo de interesados, sino que comunica los riesgos
con un enfoque de madurez y objetividad. Su frase favorita es: “¿Tenemos derecho a
creer que esto va a ocurrir según lo esperado? Si no es así, tendríamos que anticipar
estas actividades. Si ocurre el problema, entonces tenemos que prepararnos para
ejecutar de forma efectiva estas otras actividades...” Esta expresión de “¿tenemos
derecho a creer?” es la llave para abordar la gestión de riesgos con madurez.
La siguiente tabla resume algunas características que distinguen a un buen

gestor de riesgos de proyectos:
Un director de proyectos que Un director de proyectos que

NO gestiona bien los riesgos SÍ gestiona bien los riesgos
Cree que gestionar riesgos consiste en No le gusta verse sorprendido por los
estar preocupado por el proyecto. problemas: quiere problemas, no sustos.
Gestionaconfiado, “cruza los dedos” para No quiere que le sorprenda un éxito
que no ocurra nada malo. inesperado: quiere verlo venir.
Cuandole sorprende un suceso inesperado Quiere gestionar cuando hay tiempo,

que perjudica seriamente al proyecto, no cuando tiene opciones
tiene ninguna respuesta pensada de
antemano: se ve obligado a improvisar. No confía en la improvisación: Improvisar
es la peor manera de gestionar.
Imaginemos un equipo de dirección del proyecto que gestiona eficazmente los

riesgos. ¿Qué actividades realizaría?
Ejercicio 1. Describa cómo gestionó el riesgo el equipo de dirección del

proyecto en siete párrafos, usando estas palabras clave:
1. Organización ejecutora, aversión al riesgo, interesados, comité de gestión de

riesgos, solo amenazas no oportunidades, RBS, plantillas de registro de riesgos-
problemas-supuestos, reuniones de identificación, reuniones de seguimiento.
2. Brainstorming, 25 riesgos, 10 supuestos, riesgos categorizados, problemas

ocurridos en el pasado.
3. Análisis cualitativo, matriz de probabilidad e impacto, versión inicial del registro

de riesgos, riesgo R: probabilidad-impacto-importancia.
4. Análisis cuantitativo, valor monetario esperado, reservas de contingencia.
5. Aprobar acción de respuesta, actividades de mitigación-contingencia.
6. El riesgo R se materializó, impacto minimizado, disparadores.
7. Cierre del proyecto, versión final del registro de riesgos.

Solución:
1. La organización ejecutora, que tiene un perfil de aversión al riesgo, tiene como

política que todos los proyectos con presupuesto superior a 250.000€, como es de
este, sean supervisados por un Comité de Gestión de Riesgos. Tres interesados
tienen mucho poder y poco interés en el proyecto. Otros dos de ellos tienen interesas
contrapuestos. En la reunión para elaborar el plan de gestión de riesgos, el equipo de
gestión decidió que en este caso se dedicaría el esfuerzo de gestión a para tratar solo
amenazas, no oportunidades. Se decidió usar la Estructura de Desglose de Riesgos
(RBS) facilitada por la PMO. Se recopilaron las plantillas de registro de riesgos a
utilizar y cómo se registrarían
2. los problemas y los supuestos. Se decidieron las fechas y los expertos a

convocar en tres reuniones de identificación de riesgos. Se decidió que en todas las
reuniones de seguimiento se trataría el registro de riesgos actualizado con los 10
riesgos más importantes en ese momento.
3. Al concluir las reuniones de brainstorming con expertos se obtuvo una lista de

25 riesgos (que se podrían gestionar proactivamente) y otros 10 supuestos (fuera de la
zona de control del equipo de gestión). El equipo se aseguró de que se habían
considerado los riesgos categorizados por la organización y los problemas ocurridos
en el pasado en proyectos parecidos.
4. En el análisis cualitativo se utilizó una matriz de probabilidad e impacto. Se

ordenó la lista de riesgos y se preparó una versión inicial del registro de riesgos. En
una fila del registro de riesgos podía leerse la descripción básica de un riesgo
concreto, llamémoslo riesgo R: se calificó su probabilidad como “alta” y su impacto
como “muy alto”, por lo que quedó arriba de la lista, entre los más importantes.
5. El análisis del valor monetario esperado sirvió para establecer las reservas de
contingencia. El análisis cuantitativo del riesgo R determinó una exposición individual
de 30.000€, resultado de multiplicar su probabilidad por el valor económico de su
impacto (0,25 x 120.000€).
6. El comité de gestión de riesgos aprobó la acción de respuesta al riesgo R

propuesta por el equipo de gestión, valorada en 10.000€ en actividades de mitigación,
previas a la ocurrencia, más 5.000€ en reservas de contingencia. Al tomar la decisión,
los miembros del comité eran conscientes de que, si no se materializaba el problema,
los 10.000€ gastados para mitigarlo se perderían.
7. Cuando el riesgo R se materializó, el equipo de dirección del proyecto ya lo

tenía previsto, con lo que inmediatamente pudo activar la respuesta para contener su
impacto, gastando la parte asignada de la reserva para contingencias. El impacto fue
minimizado debido a las acciones de mitigación ejecutadas mucho antes. El problema
no sorprendió al equipo de gestión, sino que ya lo iban viendo venir debido a la
monitorización continua de los indicadores de transición del riesgo, o disparadores.

8. Al cierre del proyecto, en la versión final del registro de riesgos, figuraba el

riesgo R como cerrado 2 meses antes. El impacto final para el proyecto, debido a este
riesgo fue de 18.000€ de sobrecoste y 5 semanas de retraso.
9.1. Controlar los Riesgos
Controlar los Riesgos consiste en implementar los planes de respuesta a los

riesgos, monitorizar los riesgos identificados, monitorizar los riesgos residuales,
identificar nuevos riesgos y evaluar la efectividad del proceso de gestión de los riesgos
a través del proyecto. La gestión de riesgos no es algo que se haga solo al principio,
solo tiene sentido gestionar riesgos si el registro de riesgos se mantiene
continuamente actualizado. La parte buena de los riesgos es que los riesgos caducan
(el riesgo de que un proveedor entregue tarde desaparece el día de la entrega, el
riesgo de que el cliente no acepte un entregable desaparece con la aceptación, al final
del proyecto no hay ningún riesgo). En este proceso se lleva el seguimiento sobre el
estado de los riesgos, con especial atención a los más importantes y urgentes, se
monitorizan y se adaptan los planes de respuesta, se revisan los riesgos y supuestos
actuales y se identifican, analizan y responden riesgos nuevos.
Los riesgos se planifican y se controlan. El control consiste básicamente en:
Reactivar el ciclo de identificación-respuesta tantas veces como sea necesario,

para contemplar los riesgos nuevos, que pueden aparecer en cualquier momento.
Borrar los riesgos que hayan expirado, actualizando del registro de riesgos
para que sea fácil listar los riesgos activos a la fecha (los riesgos caducan: al finalizar
el proyecto no hay ningún riesgo).

Documentar lecciones aprendidas resultantes de la gestión de los riesgos:

Mantener un histórico de gestión de riesgos (un problema de ayer es un riesgo de
hoy).
Documentar los workarounds (respuestas no planificadas a problemas

imprevistos).
Re-evaluar si los supuestos siguen siendo válidos.
Supervisar los elementos de riesgo contemplados en las líneas bases de

cronograma y costes.
Vigilar los disparadores para ver si es necesario implementar los planes de

respuesta.
Vigilar riesgos residuales y secundarios, consecuencia de implementar los

planes de respuesta.
Comprobar la efectividad del proceso de gestión de riesgos.
9.1.1. ENTRADAS
Plan para la dirección del proyecto: Contiene directrices específicas sobre el

control de los riesgos (qué hay que hacer, cómo, quién, cuándo, etc.)
Registro de riesgos: Contiene las definiciones y características de los riesgos

del proyecto.
Datos de desempeño del trabajo: Específicamente, se supervisan las

actividades de mitigación y contingencia. También debe evaluarse el efecto de la
gestión de riesgos en el rendimiento global del trabajo, prestando especial atención a:
• El estado de los entregables;
• El avance del cronograma;
• Los costes incurridos.
Informes de desempeño del trabajo: Reflejan la situación del proyecto y sus

desviaciones, desde una perspectiva de gestión de riesgos, para dirigir
apropiadamente las siguientes actividades de control de riesgos.

Re-evaluación de los Riesgos: Reevaluar riesgos actuales, identificar nuevos

riesgos, y cerrar riesgos obsoletos.
Auditorías de los riesgos: Las auditorías de riesgos examinan y documentan

la efectividad de las respuestas a los riesgos identificados y sus causas, así como la
efectividad del proceso de gestión de riesgos. El director del proyecto es el
responsable de asegurar que las auditorías de riesgos se realicen con una frecuencia
apropiada, según se definió en el plan de gestión de riesgos.
Análisis de variación y de tendencias: Permiten pronosticar la desviación

potencial del proyecto a su conclusión con respecto a las metas de coste y plazo. Las
desviaciones con respecto a las líneas base de costes y cronograma pueden indicar
que algunos riesgos se han materializado, o bien que aparecen otros nuevos riesgos
(amenazas u oportunidades).
Medición del desempeño técnico: Se suelen plantear hitos técnicos (e.g.

número de hitos cumplidos, número de funcionalidades incluidas en versiones
incrementales del producto, número de defectos reportados por el equipo de pruebas,
número de requisitos validados, etc.). La comparación entre lo planificado y lo real
permite cuantificar el grado de riesgo técnico del proyecto a lo largo del tiempo.
Análisis de Reservas: Se debe supervisar cómo se van consumiendo las

reservas de presupuesto y cronograma (buffers).
Reuniones: La gestión de los riesgos del proyecto debe ser un punto del orden
del día en todas y cada una de las reuniones de seguimiento. La gestión de riesgos se
vuelve eficaz sólo si se practica a menudo.
9.1.3. SALIDAS
Información de desempeño del trabajo: proporciona un mecanismo para

comunicar y apoyar la toma de decisiones del proyecto.
Solicitudes de cambios:
• Acciones correctivas recomendadas (acciones de contingencia y

soluciones alternativas workarounds).
• Acciones preventivas recomendadas (acciones de mitigación).
Actualizaciones al plan para la dirección del proyecto: A veces, las

auditorías de riesgos encuentran alguna ineficacia en el proceso de gestión de riesgos
que debe corregirse y documentarse en el plan de gestión de riesgos.

Actualizaciones a los documentos del proyecto: Suelen actualizarse el

registro de riesgos, el registro de supuestos, documentos técnicos, etc. Las
actualizaciones al registro de riesgos provienen de:
• Los resultados de las reevaluaciones, auditorías y revisiones periódicas de los

riesgos.
• Los resultados reales de los riesgos del proyecto y de las respuestas a los
riesgos.
Actualizaciones a los Activos de los Procesos de la Organización:
• Plantillas correspondientes al plan de gestión de riesgos, incluidos la matriz

de probabilidad e impacto y el registro de riesgos;
• Las lecciones aprendidas procedentes de las actividades de gestión de los

riesgos del proyecto;
• La Estructura de Descomposición de Riesgos (Risk Breakdown Structure -

RBS-).
10. INFORME DE ESTADO DEL PROYECTO
El siguiente diagrama representa las interrelaciones entre los procesos

relacionados con la gestión de los cambios:

Las solicitudes de cambios pueden originarse mientras se están ejecutando el

trabajo del proyecto: si se detecta algún problema, generalmente no es buena práctica
reaccionar o improvisar. Un director de proyectos eficaz prefiere involucrar a los
demás en el problema y buscar juntos la solución. En cualquier caso ha de seguirse el
plan de gestión de cambios establecido y documentar la solicitud de cambio. Las
solicitudes de cambios también pueden ser consecuencia de las actividades de
monitorización y control.
Los hechos significativos que ocurren durante la ejecución del proyecto se

denominan datos de desempeño del trabajo. Esta “información en bruto” no sirve para
tomar decisiones como corresponde en el proceso 4.4 Monitorizar y Controlar el
Trabajo del Proyecto. Por esta razón, hay que transformar los “datos de desempeño”
en “información de desempeño”. Por ejemplo, que una actividad haya comenzado el
23 de abril, es un dato; que el comienzo tardío de esta actividad haya reducido el
buffer del proyecto en 3 días, es información. Como puede apreciarse en la figura, la
información de desempeño termina en el sumidero del proceso 4.4 Monitorizar y
Controlar el Trabajo del Proyecto. En este proceso, que típicamente ocurre en forma
de reunión de seguimiento, se pueden solicitar nuevos cambios también.
Como puede apreciarse en la figura, todas las solicitudes de cambios terminan

en el sumidero del proceso 4.5 Realizar el Control Integrado de Cambios. Las
solicitudes de cambios aprobadas son entrada para el proceso 4.3 Dirigir y Gestionar
el Trabajo del Proyecto. En este proceso, el equipo de dirección del proyecto trata de
seguir el plan para la dirección del proyecto y las solicitudes de cambios aprobadas.
Por lo que se refiere a los cambios, la Guía del PMBOK® distingue tres tipos de
cambios:
Acción correctiva: Una actividad que procura volver a alinear el desempeño del
trabajo del proyecto con el plan para la dirección del proyecto.
Acción preventiva: Una actividad que asegura que el desempeño futuro del
trabajo del proyecto esté alineado con el plan para la dirección del proyecto.
Reparación de defectos: Una actividad para modificar un producto o

componente de producto no conforme.
10.1. Monitorizar y Controlar el Trabajo del Proyecto
Monitorizar y Controlar el Trabajo del Proyecto es el proceso de dar

seguimiento, revisar e informar del avance del proyecto con respecto a los objetivos de
desempeño definidos en el plan para la dirección del proyecto.


actividades de monitorización y control del trabajo del proyecto:
Comparar el desempeño real del proyecto con respecto al plan para la

dirección del proyecto
Evaluar el desempeño para determinar la necesidad de una acción preventiva o

correctiva y en su caso recomendar aquellas que se consideran pertinentes
Identificar nuevos riesgos y analizar, revisar y monitorizar los riesgos existentes

del proyecto, para asegurarse de que se identifiquen los riesgos, se informe sobre su
estado y se implementen los planes apropiados de respuesta a los riesgos
Mantener, durante la ejecución del proyecto, una base de información precisa y

oportuna relativa al producto o a los productos del proyecto y a su documentación
relacionada
Proporcionar la información necesaria para sustentar el informe de estado, la

medida del avance y los pronósticos
Proporcionar pronósticos que permitan actualizar la información relativa al

coste y al cronograma actuales
Monitorizar la implementación de los cambios aprobados cuando éstos se

producen
Informar adecuadamente sobre el avance del proyecto y su estado a la

dirección del programa, cuando el proyecto forma parte de un programa global.

10.1.1. ENTRADAS
Pronósticos del cronograma: Los pronósticos del cronograma, usualmente

calculados según el estándar de gestión del valor ganado (EVM), permiten determinar
si el proyecto se encuentra todavía dentro de los rangos de retraso tolerables y para
identificar si es necesaria alguna solicitud de cambio.
Pronósticos de costes: Los pronósticos de costes usualmente calculados según

el estándar de gestión del valor ganado (EVM), permiten determinar si el proyecto se
encuentra todavía dentro de los rangos de sobrecoste tolerables o si se requiere
alguna solicitud de cambio.
Cambios validados: Un cambio validado proporciona los datos necesarios para

confirmar que el cambio se llevó a cabo de la manera adecuada.
Información de desempeño del trabajo: Los datos del desempeño del trabajo,
es decir, los hechos significativos que se producen durante la ejecución del proyecto,
no sirven para evaluar el desempeño y tomar decisiones. Estos datos en bruto han de
transformarse en información procesada a través de los distintos diferentes procesos
de control. La información de desempeño del trabajo servirá para evaluar si el proyecto
está cumpliendo los objetivos de gestión o si es necesaria alguna solicitud de cambio.
Por ejemplo, un dato de desempeño del trabajo puede ser “la actividad X ha terminado
el 23 de abril”. Durante el proceso 6.7 Control del Cronograma se transformarán este y
otros muchos datos de desempeño del cronograma en información de desempeño, del
tipo: “el proyecto tiene un retraso acumulado de 15 días, y si se sigue a este ritmo se
terminará con un retraso a la conclusión de 22 días”. Con esta información procesada
ya sí es posible tomar de decisiones de gestión.
Factores Ambientales de la Empresa: Incluyen, entre otros:
• Los estándares gubernamentales o del sector de actividad.
• Los sistemas de autorización de trabajos de la organización.
• Las tolerancias al riesgo por parte de los interesados.
• El sistema de información para la dirección de proyectos.
• Los requisitos de comunicación de la organización.
• Los procedimientos de control financiero (p.ej., informes de tiempos,

revisiones necesarias de gastos y desembolsos, códigos contables y disposiciones
contractuales estándar).

• Los procedimientos para la gestión de incidentes y defectos que definen

los controles para incidentes y defectos, la identificación y la solución de los mismos,
así como el seguimiento de los elementos de acción.
• Los procedimientos para el control de cambios, incluidos los

relacionados con las variaciones del alcance, del cronograma, del coste y de la
calidad.
• Los procedimientos de control de riesgos, que incluyen las categorías

de riesgos, la definición de la probabilidad y el impacto y la matriz de probabilidad e
impacto.
• La base de datos de medición de procesos, que se utiliza para tener a

disposición los datos de mediciones de procesos y productos.
• La base de datos de lecciones aprendidas.
Juicio de expertos: El equipo de dirección del proyecto utiliza el juicio de

expertos para interpretar la información proporcionada por los procesos de
monitorización y control. El director del proyecto, en colaboración con el equipo,
determina las acciones requeridas para asegurar que el desempeño del proyecto esté
a la altura de las expectativas.
Técnicas analíticas: En la dirección de proyectos las técnicas analíticas se

emplean para pronosticar resultados potenciales sobre la base de posibles variaciones
en las variables del proyecto o ambientales y sus relaciones con otras variables. A
continuación se citan algunos ejemplos de técnicas analíticas utilizadas en los
proyectos:
• Análisis de regresión.
• Métodos de clasificación.
• Análisis causal.
• Análisis de causa raíz.
• Métodos de pronóstico (p.ej. series temporales, construcción de

escenarios, simulación, etc.)
• Análisis de modos de fallo y efectos (FMEA).
• Análisis de árbol de fallos (FTA).
• Análisis de reservas.

• Análisis de tendencias.
• Gestión del valor ganado.
• Análisis de variación.
Sistema de Información para la Dirección de Proyectos.
Reuniones: Las reuniones pueden ser cara a cara, virtuales, formales o

informales. Pueden involucrar a miembros del equipo del proyecto, a interesados y a
otros implicados o afectados por el proyecto. Entre los tipos de reuniones se pueden
citar, entre otros, a los grupos de usuarios y a las reuniones de seguimiento.
10.1.3. SALIDAS
Solicitudes de cambios: Como consecuencia de la comparación entre los

resultados planificados y los reales, pueden emitirse solicitudes de cambios para
ampliar, ajustar o reducir el alcance del proyecto, del producto, o de los requisitos de
calidad y las líneas base del cronograma o de costes. Las solicitudes de cambios
pueden requerir la recopilación y documentación de nuevos requisitos. Los cambios
pueden impactar el plan para la dirección del proyecto, los documentos del proyecto o
los entregables del producto. Los cambios que cumplen con los criterios de control de
cambios del proyecto deben gestionarse a través del proceso integrado de control de
cambios establecido para el proyecto. Los cambios pueden incluir, entre otros:
• Acción correctiva: Una actividad intencionada que procura realinear el

desempeño del trabajo del proyecto con el plan para la dirección del proyecto.
• Acción preventiva: Una actividad intencionada que asegura que el

desempeño futuro del trabajo del proyecto esté alineado con el plan para la dirección
del proyecto.
• Reparación de defectos: Una actividad intencionada para modificar un

producto o componente de producto no conforme.
Informes de desempeño del trabajo: Los informes de desempeño del trabajo

constituyen la representación física o electrónica de la información sobre el
desempeño del trabajo recopilada en documentos del proyecto, destinada a generar
decisiones, acciones o conocimiento. La información del proyecto se puede comunicar
verbalmente de persona a persona. Sin embargo, para registrar, almacenar y en
ocasiones distribuir información sobre el desempeño del trabajo se necesita una
representación física o electrónica en forma de documentos de proyecto. Los informes
de desempeño del trabajo son un subconjunto de documentos del proyecto destinados
a crear conocimiento y generar decisiones o acciones.

Se pueden definir métricas específicas de desempeño del trabajo en el inicio

del proyecto e incluirlas en los informes normales de desempeño del trabajo que se
entregan a los interesados clave. Entre los ejemplos de informes de desempeño del
trabajo se pueden citar los informes de estado, los memorandos, las justificaciones, las
notas informativas, las recomendaciones y las actualizaciones.
Actualizaciones al plan para la dirección del proyecto: Los planes secundarios y

las líneas base son elementos susceptibles de actualización.
Actualizaciones a los documentos del proyecto: Ejemplos de documentos

• Pronósticos del cronograma y de costes.
• Informes de desempeño del trabajo.
• Registro de incidentes.

11. CIERRE ORDENADO
Una visión de alto nivel de la gestión de proyectos puede representarse de esta

forma:
La organización patrocinadora, a través de un patrocinador o bien un iniciador

externo al proyecto, solicita la realización de un proyecto, sobre la base de un caso de
negocio, un enunciado del trabajo o un acuerdo (que muchas veces es de tipo
contractual).
Si la organización ejecutora aprueba el proyecto, finalmente se observará que

se entrega formalmente un producto, servicio o resultado final a la organización
solicitante, para que lo utilicen los usuarios finales. Otro resultado que puede
observarse “desde fuera” es que se generan una serie de documentos fruto del trabajo
del proyecto.
Desde que el proyecto se solicita hasta que se entrega, tienen lugar una serie
de esfuerzos que se supone debe dirigir el director del proyecto. La Guía del PMBOK®
es precisamente una serie de buenas prácticas perfectamente estructuradas que el
director del proyecto debe conocer y dominar para no reinventar la rueda: “Todo lo que
puede necesitar un director de proyectos ya está inventado”. Sin embargo, lo primero
que debe considerar el director del proyecto es que ese proyecto “no ocurre
aisladamente”, sino que tiene lugar dentro del contexto de una organización ejecutora
y por tanto ha de tener en cuenta los factores de contorno (factores ambientales de
empresa) y los artefactos de gestión escritos o normativa obligada (activos de
procesos de la organización).

El equipo de dirección del proyecto comienza generalmente por identificar a los

interesados y documentar los requisitos de la organización solicitante.
Cuando la organización ejecutora no realiza todo el alcance el proyecto, sino

que subcontrata una o varias partes a proveedores, estos presentarán sus mejores
propuestas. Y la organización ejecutora determinará los proveedores seleccionados.
La relación con estos proveedores durante el proyecto se administrará generalmente a
través los correspondientes contratos.
Si se baja a un nivel mayor de detalle, puede apreciarse cómo se resuelven las

entradas y salidas a través de los cinco grupos de procesos:
Inicio:
A partir de la información de contexto sobre el caso de negocio, el acuerdo y/o

el enunciado del trabajo, si se aprueba el proyecto, se genera el acta de constitución
del proyecto, documento que sirve para autorizar oficialmente el proyecto dentro de la
organización ejecutora, nombrando al director de proyectos, y otorgándole el nivel de
autoridad para utilizar los recursos de la organización. La otra actividad inicial no
menos importante es la obtención de la información relevante sobre los distintos
interesados. Es buena práctica recomendada que el director del proyecto esté
presente antes de la aprobación del proyecto para que ayude a integrar toda la
información generada en el debate que ha mantenido la organización sobre si hacer o
no el proyecto, y para que ayude a elaborar el acta de constitución, destacando la
información clave para justificar el proyecto y reclamando por escrito su nivel de
autoridad.

Planificación:
A partir del acta de constitución del proyecto y el registro de interesados,

siguiendo los 24 procesos de planificación, se acaba produciendo el documento
maestro para la ejecución y el control del proyecto: el plan para la dirección del
proyecto. Entre otra mucha documentación importante, también se puede generar, si
el proyecto requiere la concurrencia de proveedores externos a la organización
ejecutora, la documentación necesaria para efectuar las adquisiciones. En este grupo
de procesos el director de proyectos debe usar su potente imaginación, como si fuera
un oráculo, o un adivino con su bola de cristal, para visualizar el futuro del proyecto:
qué habrá que hacer y qué no, cuánto durará, cuánto costará, cómo generar un
producto que logre la satisfacción del cliente o la organización solicitante, quién deberá
formar parte del equipo, qué comunicar a quién, cuándo y en qué forma, cómo
anticiparse a los problemas, qué hay que adquirir a terceros y qué estrategia hay que
seguir con los principales interesados.
Ejecución:
El director del proyecto dirige el trabajo definido en el plan del proyecto y la

implementación de las solicitudes de cambio aprobadas para obtener los entregables
planificados, manteniendo continuamente actualizados los documentos del proyecto y
registrando las comunicaciones, los incidentes y los datos de desempeño para su
posterior análisis. Su objetivo es “hacer que las cosas se hagan”, buscando más la
eficiencia que la eficacia, coordinando el trabajo que deben hacer los miembros del
equipo. Podemos decir que aquí se parece a un director de orquesta que sigue la
partitura del plan del proyecto (y de los cambios aprobados) para que suene “la
melodía del proyecto”. Cuando algo no ocurre como esperaba (p.ej., un violinista
desafina) no se para la música, simplemente se emite una solicitud de cambio para su
posterior evaluación y análisis.
Monitorización y Control:
El equipo del proyecto verifica que los entregables son correctos y el director
del proyecto gestiona la entrega y persigue la aceptación por parte del cliente o la
organización solicitante. A partir de los datos de desempeño del trabajo, se juzga si el
proyecto progresa adecuadamente, en fecha, en coste y si no es así se solicitan
cambios para volver a las líneas base. Con ayuda de su equipo núcleo y del comité de
control de cambios, el director del proyecto gestiona integradamente los cambios (que
se solicitan en la ejecución o como resultado de la monitorización y control) para
procesarlos en bloque y atendiendo a su prioridad relativa. En este grupo de procesos,
podríamos decir que el director de proyectos se parece al médico que vigila el estado
de salud del proyecto, evalúa los progresos y propone acciones para conseguir que se
cumplan los objetivos.

Cierre:
Una vez los interesados han satisfecho o superado sus expectativas y se han
aprobado los entregables, se procede al cierre ordenado del proyecto y a la
transferencia formal del producto, servicio o resultado final fruto del proyecto o la fase.
Por lo que respecta a los contratos que se gestionan durante el proyecto, cada vez
que un proveedor cierra su proyecto, la organización ejecutora debe cerrar
formalmente el contrato y así concluye la relación contractual y la responsabilidad legal
de ambas partes.
11.1. Grupo de Procesos de Cierre
Un director de proyectos se distingue de un director de servicios principalmente

por una razón: Lo que gestiona, es decir, el proyecto, se termina en un momento dado.
Ya desde su inicio nace con ese objetivo: concluir antes de una fecha prefijada.
Además del objetivo temporal, hay otros objetivos no menos importantes, como
son terminar sin exceder un presupuesto, entregando una funcionalidad determinada,
consiguiendo que el producto sea “bueno” desde el punto de vista de la organización
solicitante, etc., pero quizá lo más distintivo de un proyecto es que empieza y termina.
Uno de los hábitos que se le pide a un director de proyectos es que comience “con el
fin en la mente”. Desde el primer día del proyecto debe visualizar el destino y el
camino para llegar al mismo. Nos imaginamos cómo será esa situación final en que los
interesados “han alcanzado o superado sus expectativas” y queremos hacer todo lo
posible para llegar a ese destino. Un director de proyectos debe reconocer que el
proyecto que acaba de iniciar es una fuente de problemas que desconcertará y
molestará a mucha gente que tendrá que cambiar su forma de trabajar, en el que
ocurrirán muchos problemas, conflictos, crisis inesperadas; en el que su éxito
dependerá de que un grupo de personas que no han trabajado juntas acaben siendo
un equipo cohesionado y sinérgico; en el que los contratos que su empresa firmará
con terceros para que hagan ciertas partes del proyecto podrían terminar en los
tribunales, etc. Todo este “entuerto” debe deshacerlo el director del proyecto, por tanto
es muy natural que se imagine ese último día en que ocurre el cierre efectivo y por fin
termina todo: Ha convocado al patrocinador y un subconjunto representativo de
interesados. Ha elaborado una presentación que ha ensayado a conciencia. Se ha
puesto su mejor traje, ha preparado la sala, el proyector, los interesados ya han
llegado, es la hora. Comienza por fin esa ceremonia llamada “presentación de fin de
proyecto”, pero en su cabeza, esta presentación tiene este otro título: “Adiós, me voy”.

Seguramente, esta forma de pensar tiene fuertes implicaciones psicológicas.

¿No resulta un poco alienante que eso que nosotros hemos creado con tanta ilusión,
“nuestro proyecto”, queramos hacerlo morir desde el primer día? Sin embargo, esto es
precisamente lo que se espera de nosotros: comenzamos, ejecutamos y cerramos
proyectos. Cuando has pasado por esto muchas veces, te acabas acostumbrando a
esta última parte.
La ceremonia de cierre suele estar cargada de mensajes subliminales. Cuando

yo cierro un proyecto, reconozco las siguientes equivalencias entre lo que digo y lo
que realmente quiero decir:
Presentación de Fin de Proyecto = “Adiós, me voy”.
Logros e hitos alcanzados = “No me queda nada por entregar y lo tengo todo
aceptado”.
La documentación del proyecto se puede acceder en esta carpeta, estas son

las siguientes fases = “El producto entra en fase de operación, ya no es un proyecto,
yo no seré el responsable”.
¿Dudas o aclaraciones? = “Quien tenga algo que decir, que hable ahora o calle
para siempre”.
La reunión de cierre es la más trascendente del proyecto. Deberá gestionarse

de la manera más efectiva. No debe convocarse si aún queda algo por hacer. Aunque
esté todo aceptado, no es suficiente. Hay que “escenificarlo” para que
inequívocamente se sepa que se ha terminado. A partir de esta reunión, los
interesados ya no tienen derecho a pedir más cambios.

actividades de cierre:
Aceptación formal: Obtener la aceptación final de los entregables del proyecto

trabajando con el patrocinador y/o la organización solicitante, para confirmar que el
alcance y los entregables se han validado.
Transición: Transferir la propiedad de los entregables a los interesados

asignados de acuerdo con el plan del proyecto.
Cierre administrativo: Obtener el cierre financiero, legal y administrativo usando

prácticas generalmente aceptadas, para comunicar el cierre formal y asegurar la
liberación de responsabilidades futuras.
Informe de cierre: Distribuir el informe final del proyecto incluyendo toda la

información relativa al cierre, desviaciones e incidentes, para comunicar la situación
final del proyecto a los interesados.

Lecciones aprendidas: Recopilar las lecciones aprendidas a partir de una

revisión completa del proyecto, para crear y/o actualizar la base de conocimiento de la
organización.
Dossier del proyecto: Archivar los documentos y material del proyecto, con el
fin de retener el conocimiento de la organización, cumplir los requisitos legales, y
garantizar la disposición de la información para su uso potencial en futuros proyectos e
internos y auditorías externas.
Satisfacción de la organización solicitante: Medir la satisfacción del cliente o la

organización solicitante al final del proyecto capturando su realimentación, para
facilitar la evaluación del proyecto y mejorar las relaciones con la organización
solicitante.
En la figura pueden apreciarse los principales subgrupos del grupo de procesos

de cierre:
4.6 Cerrar el Proyecto o Fase: Finalizar todas las actividades en todos los
grupos de procesos de la dirección de proyectos para completar formalmente el
proyecto o una fase del mismo.
12.4 Cerrar las Adquisiciones: Finalizar cada adquisición para el proyecto.

11.2. Cerrar el Proyecto o Fase
Cerrar el Proyecto o Fase es el proceso de finalizar todas las actividades en

todos los grupos de procesos de la Dirección de Proyectos para completar
formalmente el proyecto o una fase del mismo.
La misión principal de este proceso es asegurar que se han completado todas

las tareas del proyecto habiendo alcanzado los objetivos del proyecto (expresados en
el acta de constitución del proyecto) y que se ha entregado el alcance completo
(descrito en el enunciado del alcance del proyecto).
Por otro lado, se han de realizar todas las actividades necesarias para cerrar
administrativamente el proyecto o fase. La metodología a seguir durante el cierre de
los proyectos suele formar parte de los activos de procesos de la organización. Puede
incluir, por ejemplo: revisiones, auditorías externas, aceptación formal del cliente, pase
a producción, elaboración de lecciones aprendidas, notificación al cliente y al
departamento financiero, resumen del proyecto para el departamento de marketing,
etc. Una sencilla lista de comprobación (checklist) puede resultar muy útil para no
olvidar ningún paso.
Incluso si el proyecto se cancela, es preciso realizar una serie de actividades

de cierre, por ejemplo: reasignación de los miembros del equipo a otros proyectos,
comunicación a los interesados, pago de facturas, decisiones sobre los entregables
¿son reaprovechables?

11.2.1. ENTRADAS
Entregables aceptados.
Activos de los Procesos de la Organización. Incluyen:
• Pautas o requisitos para el cierre del proyecto o fase;
• Información histórica y base de conocimientos de lecciones aprendidas.
Juicio de expertos.
Técnicas analíticas.
Reuniones.
11.2.3. SALIDAS
Transferencia del Producto, Servicio o Resultado Final.
Actualizaciones a los Activos de los Procesos de la Organización. Incluyen:
• Archivos del proyecto: Documentación resultante de las actividades del

proyecto, por ejemplo, el plan para la dirección del proyecto, el alcance, el coste, el
cronograma y el calendario del proyecto, los registros de riesgos y otros registros, la
documentación de la gestión de cambios, las acciones planificadas de respuesta a los
riesgos y el impacto de los riesgos.
• Documentos de cierre del proyecto o fase: Documentos de cierre del

proyecto o fase, que consisten en la documentación formal que indica la terminación
del proyecto o fase y la transferencia de los entregables completos del proyecto o fase
a terceros, como por ejemplo a un grupo de operaciones o a la siguiente fase. Durante
el cierre del proyecto, el director del proyecto revisa la documentación de la fase
anterior, la documentación de aceptación del cliente procedente del proceso 5.4
Validar el Alcance y el contrato (si corresponde) para asegurarse de que todos los
requisitos del proyecto están completos antes de finalizar el cierre del proyecto. Si el
proyecto se da por concluido antes de su terminación, la documentación formal indica
por qué se concluyó el proyecto y formaliza los procedimientos para la transferencia a
terceros de los entregables terminados y sin terminar del proyecto cancelado.

• Información histórica: La información histórica y la proveniente de

lecciones aprendidas se transfieren a la base de conocimientos de lecciones
aprendidas para su utilización en futuros proyectos o fases. Esto puede incluir
información sobre incidentes y riesgos, así como sobre técnicas que funcionaron bien
y que pueden aplicarse en proyectos futuros.
11.3. Cerrar las Adquisiciones
Cerrar las Adquisiciones es el proceso de finalizar cada adquisición para el

proyecto. El beneficio clave de este proceso es que documenta los acuerdos y la
documentación relacionada para futura referencia. Este proceso se realiza cada vez
por cada acuerdo o contrato.
La finalización anticipada de un contrato es un caso especial de cierre de una

adquisición, que puede deberse a un acuerdo mutuo entre las partes, al
incumplimiento de una de las partes o a la conveniencia del comprador. Los derechos
y obligaciones de las partes en caso de finalización anticipada están incluidos en una
cláusula de finalización del contrato. Según los términos y condiciones de la
adquisición, el comprador puede tener derecho a dar por finalizada la totalidad del
contrato o una parte del proyecto, en cualquier momento, por justa causa o por
conveniencia. Sin embargo, es posible que el comprador tenga que compensar al
vendedor por los trabajos completados y aceptados relacionados con la parte del
contrato rescindida.

En toda relación contractual, el acuerdo definitivo y equitativo de todos los

asuntos, reclamaciones y controversias pendientes a través de la negociación es un
objetivo fundamental. En los casos en que no es factible llegar a un acuerdo mediante
la negociación directa, puede examinarse el empleo de algún método alternativo para
la resolución de conflictos (en inglés, Alternative Dispute Resolution -ADR-),
incluyendo la mediación o el arbitraje. Cuando todo recurso falla, iniciar un litigio en los
tribunales es la opción menos deseable.
11.3.1. ENTRADAS
Plan para la dirección del proyecto: Incluye el plan de gestión de las

adquisiciones, que proporciona los detalles y las guías para llevar a cabo el cierre de
las adquisiciones.
Documentos de la adquisición: Para cerrar el contrato, se recopila, clasifica y

archiva toda la documentación de la adquisición. Se cataloga la información del
contrato relativa al cronograma, al alcance, a la calidad y al desempeño de costes,
junto con toda la documentación sobre cambios del contrato, registros de pago y
resultados de las inspecciones. Esta información se puede utilizar para las lecciones
aprendidas y como base de evaluación de contratistas para contratos futuros.
Auditorías de la Adquisición: Es una revisión estructurada de los procesos de

gestión de la adquisición. El objetivo es identificar los éxitos y los fallos que merecen
ser reconocidos en la preparación o administración de otros contratos de adquisición
en el proyecto, o en otros proyectos dentro de la organización ejecutora.
Negociación de la adquisiciones: De los cuatro tipos de acuerdos ante disputas

o reclamaciones (litigio, arbitraje, mediación, negociación) la negociación siempre es el
método preferible (ir a juicio es lo más desaconsejable).
Sistema de gestión de registros: Para almacenar toda la documentación de la

adquisición. Es parte del sistema de información de gestión de proyectos.

11.3.3. SALIDAS
Adquisiciones Cerradas: El comprador, mediante un administrador de la

adquisición autorizado, proporciona al proveedor una notificación formal por escrito de
que el contrato ha sido completado. Habitualmente, los requisitos para el cierre formal
de la adquisición se definen en los términos y condiciones del contrato, y se incluyen
en el plan de gestión de las adquisiciones.
Actualizaciones a los Activos de los Procesos de la Organización. Incluyendo:
• El archivo de la adquisición: Juego completo indexado de la

documentación del contrato, incluido el contrato cerrado, para su incorporación a los
archivos finales del proyecto.
• La aceptación de los entregables.
• La documentación sobre lecciones aprendidas.
12. LECCIONES APRENDIDAS Y GESTION DEL

CONOCIMIENTO
Un proyecto no es solo un conjunto de tareas relacionadas. Es una asignación

que debe terminar sin exceder un plazo y un presupuesto, cumpliendo unos criterios
de calidad.
En las organizaciones se distinguen principalmente dos tipos de actividades:

operaciones y proyectos. Las operaciones consisten básicamente en tareas
repetitivas, la producción, la administración de los recursos para "mantener las luces
encendidas".
La gestión de proyectos hace posible los cambios en las organizaciones. Una

organización necesita gestionar proyectos cuando necesita crear nuevos productos y
servicios, ejecutar las propuestas del plan estratégico, expandirse a nuevas regiones,
a nuevos sectores, lanzar nuevas líneas de negocio, implantar cambios tecnológicos,
etc. Todo esto no se gestiona agrupando tareas, sino a través de un cuerpo de
conocimientos que básicamente permiten “proyectar” el futuro, para después
conseguir los objetivos de tiempo, coste, alcance y calidad. Aquí la figura clave es el
director de proyectos (project manager, en inglés), alguien encargado no de hacer las
cosas, sino de hacer que las cosas se hagan. El director de proyectos debe dominar
muchas técnicas de gestión, pero sobre todo ha de ser buen negociador, buen
comunicador y buen líder.

La organización de gestión de proyectos más reconocida a nivel mundial es el

Project Management Institute (el PMI®), fundada en Pensilvania en 1969 y
actualmente con unos 500.000 afiliados y presencia en casi 200 países. El PMI®
defiende que la dirección de proyectos es una profesión, que el director de proyectos
debe cumplir un código deontológico y que debe mantenerse permanentemente
actualizado.
En un entorno empresarial cada día más competitivo y selectivo, en el que sólo

sobreviven las empresas que más rápidamente saben adaptarse a las necesidades
cambiantes de sus clientes, gestionar proyectos de forma óptima es irrenunciable, ya
no sólo para seguir en la brecha, sino para la generación de futuro y la sostenibilidad.
Hasta ahora ha sido importante optimizar las operaciones, y ya se ha recorrido un
largo camino en este sentido (especialización, factorías, globalización, herramientas,
procesos, sistemas de calidad lean, seis-sigma, etc.). Estos métodos han sido muy
efectivos para aumentar la productividad y reducir los costes operativos. Sin embargo,
proyectos y operaciones son unidades de gestión bien distintas. Según el PMI®, un
proyecto es "una asignación temporal para crear un producto, servicio o resultado
único". Es decir, un proyecto es algo que nunca se ha hecho antes igual, se realiza
con un equipo de personas que la mayoría de las veces trabajan juntas por primera
vez, y que suele tener unas restricciones fuertes de alcance, tiempo, coste, calidad,
etc. Además, en un proyecto hay mucho en juego. Hay mucho interesado, gente que
gana o pierde con el proyecto. Hay muchas posibilidades de que un proyecto sea un
éxito, pero también hay muchas posibilidades de que sea un rotundo fracaso, que
llegue a impactar la imagen de la empresa, o incluso llegue a afectar al valor de la
acción.
La buena noticia es que prácticamente todo lo que debe saber el director de

proyectos ya está inventado. Los grandes proyectos, como por ejemplo “llevar a un
hombre a la luna” o “remodelar el Canal de Panamá”, requieren la aplicación de toda
una serie de procesos. Cuando un director de proyectos asume un proyecto de estas
características, debe imponer un esquema de control basado en procesos. Si estos
procesos no forman parte del cuerpo normativo de la organización ejecutora, el
director de proyectos tiene la responsabilidad de crearlos para poder aplicarlos. Los
directores de proyectos pueden agradecer al PMI® el empeño y la constancia de más
de 40 años formalizando todas las áreas de conocimiento aplicables.
12.1. La Guía del PMBOK®
La Guía de los Fundamentos para la Dirección de Proyectos (A Guide to the

Project Management Body of Knowledge, PMBOK® Guide) se publicó por primera vez
como whitepaper por el PMI® en 1983, con el propósito de documentar y estandarizar
las prácticas comúnmente aceptadas en gestión de proyectos. Pronto se convirtió en
un estándar ANSI que se reedita cada cuatro años.

La primera edición se publicó en 1996, y la última edición hasta ahora, la

quinta, fue publicada en diciembre de 2012. En la actualidad está traducida a 10
idiomas, además del inglés y se calcula que circulan más de 4 millones de copias en
todo el mundo. Hoy día podemos decir que se trata del estándar más globalmente
reconocido en todas las comunidades de dirección de proyectos.
La Guía del PMBOK® es un libro con trece capítulos, cuatro anexos y un

glosario:
Sección I – Marco Conceptual de la Dirección de Proyectos:
Capítulo 1 – Introducción
Capítulo 2 – Influencia de la Organización y Ciclo de Vida del Proyecto
Capítulo 3 – Procesos de la Dirección de Proyectos
Sección II – Áreas de Conocimiento de la Dirección de Proyectos:
Capítulo 4 – Gestión de la Integración del Proyecto
Capítulo 5 – Gestión del Alcance del Proyecto
Capítulo 6 – Gestión del Tiempo del Proyecto
Capítulo 7 – Gestión de los Costes del Proyecto
Capítulo 8 – Gestión de la Calidad del Proyecto
Capítulo 9 – Gestión de los Recursos Humanos del Proyecto
Capítulo 10 – Gestión de las Comunicaciones del Proyecto
Capítulo 11 – Gestión de los Riesgos del Proyecto
Capítulo 12 – Gestión de las Adquisiciones del Proyecto
Capítulo 13 – Gestión de los Interesados del Proyecto

Anexos destacados:
Anexo A1 – El estándar para la gestión de proyectos
Anexo X3 – Habilidades interpersonales
Glosario
Es importante recalcar que la Guía del PMBOK® es una guía, no una

metodología. Es más bien un meta modelo: dice qué hay que hacer, pero no cómo hay
que hacerlo. La gestión de cada proyecto es única, y es responsabilidad del director de
proyectos, junto con su equipo de gestión, decidir qué procesos aplican, cómo han de
configurarse los entregables, cómo han de procesarse los cambios, cómo hay que
gestionar los riesgos, las comunicaciones, la calidad, las adquisiciones, etc. Una
metodología describe una forma determinada de realizar los trabajos. La Guía del
PMBOK® no prescribe la forma exacta de ejecutar los proyectos. Se trata de un marco
de referencia que se puede implantar con distintas metodologías de dirección de
proyectos (como metodologías ágiles, en cascada, PRINCE2, etc.).
El cuerpo principal de la guía se centra en el desarrollo de las 10 áreas de

conocimiento:
4. Gestión de la Integración Identificar, definir, combinar, unificar y coordinar los diversos

del Proyecto procesos y actividades de dirección del proyecto.
5. Gestión del Alcance Garantizar que el proyecto incluye todo el trabajo requerido y
del Proyecto únicamente el trabajo requerido para completarlo con éxito.
6. Gestión del Tiempo Gestionar para que el proyecto termine dentro del plazo
del Proyecto previsto.
7. Gestión de los Costes Planificar, estimar, presupuestar, financiar, obtener
del Proyecto financiamiento, gestionar, y controlar los costes de modo que se
complete el proyecto dentro del presupuesto aprobado.
8. Gestión de la Calidad Determinar responsabilidades, objetivos y políticas de calidad a
del Proyecto fin de que el proyecto satisfaga las necesidades para las que se
lleva a cabo.
9. Gestión de los Recursos Organizar, gestionar y liderar al equipo del proyecto.
Humanos del Proyecto
10. Gestión de las Garantizar la oportuna y adecuada recopilación, creación,
Comunicaciones distribución, almacenamiento, recuperación, gestión, control,
del Proyecto monitorización y disposición final de la información del proyecto.
11. Gestión de los Riesgos Identificar, analizar, planificar las respuestas y controlar las
del Proyecto incertidumbres del proyecto.
12. Gestión de las Comprar o adquirir los productos, servicios o resultados
Adquisiciones del requeridos por terceros ajenos a la organización.
Proyecto
13. Gestión de los Identificar a todas las personas u organizaciones impactadas por
Interesados del Proyecto el proyecto, analizar sus expectativas y su impacto en el
proyecto, y desarrollar estrategias de gestión adecuadas para
lograr la participación eficaz de los interesados en las decisiones
y en la ejecución del proyecto.

Por otra parte, en cualquier proyecto se reconocen 5 grupos de procesos:
Inicio Definir el nuevo proyecto o fase mediante la obtención de la autorización para

comenzar.
Planificación Establecer el alcance del proyecto, refinar los objetivos y definir el curso de
acción requerido para alcanzar los objetivos propuestos.
Ejecución Completar el trabajo definido en el plan para la dirección del proyecto a fin de
satisfacer las especificaciones del mismo.
Monitorización Monitorizar, analizar y regular el progreso y el desempeño del proyecto, para
y Control identificar áreas en las que el plan requiera cambios y para iniciar los cambios
correspondientes.
Cierre Finalizar todas las actividades a fin de cerrar formalmente el proyecto o una fase
del mismo.
Esta forma de agrupar los procesos que propone la Guía del PMBOK® nos
habla de especialización y objetivos de gestión a lo largo de un proyecto. Mientras que
las áreas de conocimiento se refieren a qué hay que saber para gestionar cualquier
proyecto, los grupos de procesos dicen qué hay que obtener en todo proyecto o fase
En el inicio hay que hacer que la organización tenga un debate estratégico

sobre si el proyecto está alineado, es oportuno y es más prioritario que otros, pues no
habrá recursos para ejecutar todas las iniciativas.
En la planificación hay que “pensar antes de hacer”, hay que imaginar el

proyecto hasta donde alcance la información disponible y tratar de cerrar una
planificación completa (donde no se sabe todavía, se toman supuestos).
Cuando el proyecto está en marcha, hay que distinguir la ejecución (hacer que
las cosas se hagan, producir entregables de forma eficiente) del control (separarse del
trabajo para opinar y juzgar si es factible cumplir los objetivos, y tomar acciones para
corregir o mejorar el desempeño).
Finalmente, los proyectos se cierran, lo que quizá sea lo más distintivo de la

gestión de proyectos frente a la gestión de operaciones. Al director del proyecto le
gusta decir adiós: se asegura de que todo está terminado y entonces procede a cerrar
formalmente el proyecto para transferir los resultados a la siguiente fase, al cliente, o a
la unidad organizativa correspondiente.
Obsérvese que los grupos de procesos son consistentes con el modelo de

mejora continua PDCA de Deming: Plan = planificación; Do = ejecución; Check, Act =
control.

Según la Guía del PMBOK®, un proyecto completo se gestiona siguiendo estos

grupos de procesos desde su inicio (cuando aún no se ha aprobado) hasta su cierre
(cuando todo está terminado y hay que formalizar su conclusión). Cuando un proyecto
se divide en fases secuenciales, los procesos de la Guía del PMBOK® se pueden
aplicar de igual manera, es decir: al comienzo de la primera fase habrá que justificar
detalladamente el proyecto; y cuando termine esa fase habrá que cerrarla oficialmente
para volver a pensar si se dan las condiciones para continuar con el lanzamiento de la
siguiente fase. El proyecto podría cancelarse si ya no es oportuno. Si se aprueba,
habría que elaborar el acta de constitución para iniciar la siguiente fase.
Es decir, en todo proyecto o fase se puede plantear la gestión siguiendo los

grupos de inicio, planificación, ejecución, control y cierre. El acrónimo IPECC sirve
para recordar estos cinco grandes grupos de gestión.
Por último, hay que tener en cuenta que los grupos de procesos no son
secuenciales necesariamente (no confundir grupos de procesos y fases del proyecto):
Los grupos de inicio y cierre tendrán lugar al principio y final del proyecto o
fase, respectivamente.
Las tareas de planificación (estimación de tiempos, costes, recursos, riesgos,

etc.) suelen mezclarse con las de inicio (mientras se está decidiendo si el proyecto se
realiza o no). A veces se decide que no se aprueba un proyecto porque resulta
demasiado largo, caro, incierto, no hay recursos disponibles, no pueden
subcontratarse algunas partes necesarias, etc.
Algunas actividades del proyecto pueden comenzar su ejecución (y control) aun

cuando no se ha completado la planificación. Algunos proyectos necesitan realizar
planes de negocio, estudios de viabilidad, pruebas de concepto, etc., para saber si son
factibles o no.
La planificación puede refinarse a medida que se conozcan mejor los detalles

del proyecto (elaboración progresiva).
La monitorización y el control tienen lugar durante todo el proyecto, desde su

inicio hasta su fin.

Los 47 procesos descritos en la Guía del PMBOK® pueden representarse

resumidamente en el siguiente mapa de procesos, en inglés y en español,
respectivamente:

Un elemento importante en la gestión de cualquier proyecto es la

documentación. La Guía del PMBOK® distingue entre los documentos del proyecto,
que asisten al director del proyecto en la gestión del proyecto, y el plan para la
dirección del proyecto, que se compone de una serie de planes secundarios.

Change management plan Activity attributes Project schedule
Communications Activity cost estimates Project schedule network

management plan diagrams
Activity duration estimates
Configuration management Project staff assignments
plan Activity list
Project statement of work
Cost baseline Activity resource
requirements Quality checklists
Cost management plan
Agreements Quality control
Human resource measurements
management plan Assumption log
Quality metrics
Process improvement plan Basis of estimates
Requirements
Procurement management Change log documentation
plan
Change requests Requirements traceability
Scope baseline matrix
Forecasts
- Project scope Resource breakdown
- Cost forecasts
statement structure
- Schedule forecasts
- WBS Resource calendars
Issue log
- WBS dictionary Risk register
Milestone list
Quality management plan Schedule data
Procurement documents
Requirements Seller proposals
management plan Procurement statement of
Source selection criteria
work
Risk management plan
Stakeholder register
Project calendars
Schedule baseline
Team performance
Project charter
Schedule management assessments
plan Project funding
Work performance data
requirements
Scope management plan
Work performance
Stakeholder management information
plan
Work performance reports


Proyecto
Plan de gestión de los Atributos de las actividades Cronograma del proyecto

cambios
Estimación de costes de las Diagramas de red del
Plan de gestión de las actividades cronograma del proyecto
comunicaciones
Estimación de la duración Asignaciones de personal al
Plan de gestión de la de las actividades proyecto
configuración
Lista de actividades Enunciado del trabajo del
Línea base de costes proyecto
Requisitos de recursos de
Plan de gestión de los las actividades Listas de verificación de
costes calidad
Acuerdos
Plan de gestión de los Mediciones de control de
recursos humanos Registro de supuestos calidad
Plan de mejoras del Base de las estimaciones Métricas de calidad

proceso
Registro de cambios Documentación de
Plan de gestión de las requisitos
Solicitudes de cambios
adquisiciones
Matriz de trazabilidad de
Pronósticos
Línea base del alcance requisitos
- Pronósticos de costes
- Enunciado del Estructura de desglose de
alcance del proyecto - Pronósticos del recursos
cronograma
- EDT/WBS Calendarios de recursos
Registro de incidentes
- Diccionario de la Registro de riesgos
EDT/WBS Lista de hitos
Datos del cronograma
Plan de gestión de la Documentos de las
calidad Propuestas de los
adquisiciones
proveedores
Plan de gestión de los Enunciado del trabajo
requisitos Criteriosde selección de
relativo a adquisiciones
proveedores
Plan de gestión de los Calendarios del proyecto
riesgos Registro de interesados
Acta de constitución del
Línea base del cronograma Evaluaciones del
proyecto
desempeño del equipo
Plan de gestión del Requisitos de financiación
cronograma Datos de desempeño del
del proyecto
trabajo
Plan de gestión del alcance
Información de desempeño
Plan de gestión de los del trabajo
interesados
Informes de desempeño del
trabajo

12.2. Terminología común en Dirección de Proyectos
Dirección de Proyectos
La Guía del PMBOK® define la dirección de proyectos como: la aplicación de

conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto
para cumplir con los requisitos del mismo.
Dirigir un proyecto por lo general incluye, entre otros aspectos:
Identificar requisitos.
Abordar las diversas necesidades, inquietudes y expectativas de los

interesados en la planificación y la ejecución del proyecto.
Establecer, mantener y realizar comunicaciones activas, eficaces y de

naturaleza colaborativa entre los interesados.
Gestionar a los interesados para cumplir los requisitos del proyecto y generar
los entregables del mismo.
Equilibrar las restricciones contrapuestas del proyecto que incluyen, entre

otras:
• El alcance.
• La calidad.
• El cronograma.
• El presupuesto.
• Los recursos.
• Los riesgos.
Proyecto, Programa y Portafolio
La Guía del PMBOK® proporciona las siguientes definiciones de proyecto,

programa y portafolio:

Proyecto: Esfuerzo temporal que se lleva a cabo para crear un producto,

servicio o resultado único.
Programa: Grupo de proyectos, subprogramas y actividades de programas

relacionados cuya gestión se realiza de manera coordinada para obtener beneficios
que no se obtendrían si se gestionaran en forma individual. Pueden incluir operaciones
fuera del alcance de los proyectos.
Portafolio (Cartera): Proyectos, programas, subportafolios y operaciones

gestionados como un grupo para alcanzar los objetivos estratégicos. Los
componentes de la cartera no tienen por qué ser interdependientes o estar
directamente relacionados.
Modelo de Madurez OPM3®
El modelo de madurez en gestión de proyectos corporativa propuesto por el

PMI® se denomina OPM3® (Organizational Project Management Maturity Model).
Contiene un conjunto de preguntas para determinar la madurez en gestión de
proyectos, programas y portafolios. A partir de los resultados, se propone un roadmap
de mejora con objetivos muy detallados y criterios de éxito (600 mejores prácticas,
2100 capacidades, 2200 indicadores clave de desempeño). Las evaluaciones de
madurez pueden ser realizadas oficialmente por personas con la titulación Certificado
Profesional en OPM3®.

Interesados (Stakeholders)
Son personas y organizaciones (e.g. clientes, patrocinadores, organización

ejecutora, público), involucrados activamente en el proyecto, o cuyos intereses pueden
verse afectados de manera positiva o negativa por la ejecución o conclusión del
proyecto. También pueden influir sobre el proyecto y sus entregables. Es una tarea
crítica del director del proyecto el transformar (combinar) las expectativas de los
diversos interesados en un conjunto coherente y manejable, favorable a los objetivos y
las necesidades del proyecto. Los interesados presentes en los proyectos son, entre
otros:
El Director del Proyecto (Project Manager).
El Cliente: Interlocutor directo para el equipo de dirección del proyecto, entre

otras funciones, participa en las reuniones de seguimiento, da el visto bueno en la
verificación de los entregables, etc.
El usuario: Personas que usarán el producto del proyecto.
La organización ejecutora: La empresa para la que trabaja el equipo del

proyecto.
Los miembros del equipo del proyecto: Las personas que realizan el trabajo.
El equipo de dirección del proyecto: El grupo que gestiona la ejecución del

proyecto, entre los que se encuentra el Director del Proyecto y algunos miembros
destacados del equipo. Es responsable de identificar a los diferentes interesados, sus
requerimientos, expectativas y objetivos, que suelen ser diferentes.
El patrocinador: Primer interesado en la conclusión exitosa del proyecto.

Persona o grupo que asigna el presupuesto al proyecto y lo autoriza.
Influyentes: Personas no directamente relacionadas con el proyecto pero que

pueden impactar en sus resultados.
La Oficina de Gestión de Proyectos o Programas (PMO).

Restricciones Contrapuestas (Competing Constraints)
Se denomina restricción a cualquier circunstancia que limite las opciones del

equipo de dirección del proyecto. Cualquier restricción aplicable, ya sea interna o
externa, puede afectar al desempeño del proyecto o de un proceso. Por ejemplo, una
restricción del cronograma suele presentarse bajo la forma de fechas fijas impuestas.
Tienen carácter contrapuesto porque variar cualquier restricción afecta al menos en
otra. Por ejemplo, reducir el plazo implica aumentar el presupuesto.
En versiones anteriores de la guía PMBOK se citaba “la triple restricción” plazo,

presupuesto y alcance. La versión actual amplía a 6 las restricciones típicas (además
de las 3 anteriores: recursos, riesgos y calidad) y deja abierta la posibilidad de que
sean aplicables otras, dependiendo de las características del proyecto (como pueden
ser la satisfacción del cliente, las dependencias con otros proyectos, etc.)
Estas restricciones de gestión son contrapuestas, en el sentido de que si se

altera una de ellas, generalmente impacta en las otras. He aquí algunos ejemplos:
Alcance: Si el equipo de dirección del proyecto decide aumentar el alcance

(hay que generar 10 entregables más, por ejemplo), supondrá más presupuesto y más
plazo. Si por ejemplo el plazo no puede aumentarse, podría afectar a la calidad de los
entregables, porque hay menos tiempo para hacerlos del que originalmente se
planificó.
Plazo: Si hay que reducir el plazo, como consecuencia habrá que reducir el
alcance. Si el plazo aumenta (como consecuencia de un mayor alcance), habrá que
aumentar el presupuesto.
Presupuesto: Si el presupuesto se reduce, la consecuencia es reducir el

alcance. Si no se reduce el alcance, se penaliza la calidad. Si el presupuesto aumenta
(porque aumenta el alcance), también habrá que aumentar el plazo.
Recursos (materiales y humanos): A mayor disponibilidad de recursos, menor

plazo (y coste).

Riesgos: Si una persona clave trabaja a la vez en varios proyectos, y uno se

retrasa, es muy probable que el otro también se retrase. En general, si los riesgos no
se consideran anticipadamente, pueden afectar al alcance, presupuesto, plazo,
calidad, etc. Responder a los riesgos limita las opciones de gestión.
Supuestos (Assumptions)
Los supuestos son factores que, para los propósitos de la planificación, se

consideran verdaderos, reales o ciertos, sin necesidad de contar con evidencia o
demostración.
En los proyectos, sobre todo al principio, hay demasiadas incógnitas, tantas

que parece imposible estimar detalladamente plazos, presupuestos, recursos, etc.
Para completar una planificación realista, donde no sabemos, tomamos supuestos.
Por ejemplo: “suponiendo que el proveedor entrega el hardware tal fecha, suponiendo
que los técnicos tienen esta tasa de productividad, suponiendo que el cliente asigna a
este personal clave que necesito para validar los requisitos a partir de tal fecha,
suponiendo… Entonces puedo estimar como fecha de entrega entre el 20 de abril y el
15 de mayo, con una confianza del 65%”
Estos supuestos han de monitorizarse continuamente, con el fin de mantener

actualizada la planificación a medida que vamos descubriendo nueva información del
proyecto. Normalmente se utiliza un registro de supuestos (assumption log).
Elaboración Progresiva
A veces se denomina también planificación gradual, progressive elaboration,

rolling wave planning, etc. Es una técnica que consiste en mejorar y agregar detalles
continuamente a un plan en la medida en que se cuente con información más
detallada y específica y con estimaciones más precisas, a medida que el proyecto
avanza. De ese modo se podrán producir planes más precisos y completos que sean
el resultado de las reiteraciones sucesivas del proceso de planificación.
Para practicar la elaboración progresiva, se pueden distinguir en el alcance

aquellos paquetes de trabajos sobre los que aún no se tienen suficientes detalles, que
esperamos descubrir más adelante (p.ej., dentro de 2 meses, en un proyecto de un
año). A estos paquetes no los llamamos paquetes de trabajo, sino paquetes de
planificación. Cuando se conocen los detalles, estos paquetes de planificación se
descomponen en paquetes de trabajo. En un cronograma no suelen representarse
dichos los paquetes de planificación (o bien pueden representarse como tareas
resumen con fechas estimativas, sin descomposición en actividades detalladas).

Oficina de Gestión de Proyectos o Programas (PMO)
Un cuerpo o entidad de la organización que tiene varias responsabilidades

asignadas con relación a la dirección centralizada y coordinada de aquellos proyectos
que se encuentran bajo su jurisdicción. Las responsabilidades de una oficina de
dirección de proyectos pueden variar, desde realizar funciones de apoyo para la
dirección de proyectos hasta ser realmente los responsables de la dirección de un
proyecto.
Puede ser de varios tipos:
PMO de apoyo (supportive PMO):
• Desempeñan un rol consultivo de cara a los proyectos, suministrando

plantillas, mejores prácticas, capacitación, acceso a la información y lecciones
aprendidas de otros proyectos.
• Sirve como repositorio para los proyectos.
PMO de control (controlling PMO):
• Proporcionan soporte y exigen cumplimiento por diferentes medios.
• Este cumplimiento puede implicar la adopción de marcos o

metodologías de dirección de proyectos a través de plantillas, formularios y
herramientas específicos, o conformidad en términos de gobierno.
PMO directiva (directive PMO):
• Ejerce n el control de los proyectos asumiendo la propia dirección de

los mismos.

Sistema de Información para la Dirección de Proyectos
El Sistema de Información para la Dirección de Proyectos (Project Management

Information System –PMIS-) es un sistema de información compuesto por
herramientas y técnicas utilizado para recopilar, integrar y difundir los resultados de los
procesos de dirección de proyectos. Se usa para respaldar todos los aspectos del
proyecto desde el comienzo hasta el cierre, y puede incluir tanto sistemas manuales
como automatizados.
Un término relacionado con el PMIS es el Sistema de Gestión de Proyectos:

conjunto de herramientas, tecnología, metodología, recursos y procedimientos que se
usa para realizar un proyecto. La PMO también lo usa.
Muchas veces se confunden estos dos términos entre sí, y también con las
herramientas corporativas de gestión de portafolios (Project Portfolio Management –
PPM-). Hay que saber que un Sistema de Información para la Dirección de Proyectos
no se compone solo de herramientas. Las herramientas de gestión de proyectos están
experimentando un notable crecimiento. En la actualidad hay muchas herramientas a
disposición del equipo de dirección del proyecto. Por otro lado, ya no se habla solo de
herramientas de gestión de proyectos, sino que cada día es más frecuente ver cómo
estas herramientas se especializan en tareas (task management tools, como Asana),
documentos (Enterprise Content Management tools –ECM-, como Dropbox, Google
Drive, etc.), herramientas para colaborar en línea por internet (como Skype,
GoToMeeting, etc.)
Activos de los Procesos de la Organización (APO)
Los Activos de los Procesos de la Organización, que se abrevia como APO (en
inglés se dice Organizational Process Assets –OPA-) son los planes, procesos,
políticas, procedimientos y bases de conocimiento específicos de la organización
ejecutora. Abarcan planes, políticas, procedimientos y directrices, ya sean formales o
informales.
Pueden referirse a procesos y procedimientos relativos a los procesos de

gestión de los grupos de inicio, planificación, ejecución, control y cierre.
También abarcan las bases de conocimiento de la organización, como las

lecciones aprendidas y la información histórica. En su más amplio sentido, cualquier
documento generado en cualquier proyecto (actas, informes, planes, cronogramas,
plantillas, bases para las estimaciones, presentaciones finales, comunicaciones, etc.)
es susceptible de poder reutilizarse como APO.
Factores Ambientales de la Empresa (FAE)
Los Factores Ambientales de la Empresa, que se abrevia como FAE (en inglés
se dice Enterprise Environmental Factors –EEF-) hacen referencia a condiciones que
no están bajo el control del equipo del proyecto y que influyen, restringen o dirigen el
proyecto. Entre los factores ambientales de la empresa, se incluyen:

La cultura, estructura y gobierno de la organización.
La distribución geográfica de instalaciones y recursos.
Los estándares de la industria o gubernamentales.
Las infraestructuras.
Los recursos humanos existentes.
La administración de personal.
Los sistemas de autorización de trabajos de la empresa.
Las condiciones del mercado.
La tolerancia al riesgo por parte de los interesados.
El clima político.
Los canales de comunicación establecidos en la organización.
Las bases de datos comerciales.
El sistema de información para la dirección de proyectos.
Ciclo de Vida de un Producto
El ciclo de vida de un proyecto es generalmente parte del ciclo de vida de un

producto. El ciclo de vida de un producto abarca desde su concepción hasta su
retirada del mercado. Generalmente comienza con un plan de negocio, sigue el
proyecto que genera el producto. Después de finalizar el proyecto comienza la fase de
operación y soporte del producto.

Fases de un Proyecto
El ciclo de vida de un proyecto abarca las fases necesarias en un proyecto

desde su principio a su fin. Un proyecto generalmente se divide en fases. Cada fase
puede representarse así:
El ciclo de vida de un proyecto puede verse como una sucesión de fases. Cada
fase concluye cuando se revisan y aprueban sus entregables. Un entregable es un
producto que debe poder medirse y verificarse. Estos hitos de revisión al final de cada
fase se denominan "stage gates", "phase exits" o "kill points".
Cuando se aprueba la finalización de una fase, esto no significa

necesariamente que automáticamente comience la fase siguiente. Debe obtenerse
antes otra aprobación y ha de celebrarse otra reunión de lanzamiento. La transición
entre una fase y la siguiente supone la aprobación de ciertos entregables.
Generalmente, en cada fase se define:
El trabajo que ha de realizarse.
Los hitos de entrega.
Los recursos necesarios.
Los mecanismos de control a utilizar.
En cada fase, el coste suele ser bajo al principio, alto en la parte intermedia y
vuelve a bajar al final:
Al comienzo, se realiza la planificación que no genera muchos costes.
Después viene la ejecución del proyecto, donde se desarrolla el trabajo

planificado e involucrando a muchas personas, se compran materiales y se ejecutan
todas las tareas, lo cual cuesta mucho dinero.
A la conclusión, las personas van pasando a otros proyectos, lo cual reduce los
costes.

En cada fase, las incertidumbres y los riesgos son altos al principio y bajos al
final. La razón por la que ocurre esto se denomina "elaboración progresiva":
Al principio, los objetivos son amplios, y se van concretando en objetivos

detallados progresivamente.
Lo mismo ocurre con las actividades: Al principio se tienen actividades de alto

nivel, y se van definiendo a medida que el proyecto avanza.
En cada fase, la influencia de los interesados es alta al principio y baja al final,

debido al coste que tendrían los cambios. Por ejemplo, si 10 días antes de finalizar un
proyecto de construcción de un edificio se decide añadir una 4ª planta, los costes
serían desproporcionados, comparados con los costes si la decisión se hubiera
tomado durante la planificación.
La Organización y la Cultura de la Organización Ejecutora
Ejemplos de empresas con organización diferente:
Empresas que se dedican a realizar proyectos para otras empresas (e.g.

empresas de consultoría): Estas organizaciones ejecutan un proyecto tras otro para
sus clientes.
Empresas que han adoptado la gestión por proyectos (e.g. fabricante de

teléfonos móviles que lanza un proyecto para generar cada nuevo producto). Han
implementado sistemas y procesos de gestión de proyectos para desarrollar sus
operaciones.
Empresas no orientadas a la gestión por proyectos. Carecen de herramientas y

procesos para gestionar proyectos. Es menos probable la ejecución exitosa de un
proyecto en este tipo de organizaciones.
Ejemplos de empresas con tipos de cultura diferente:
Empresas emprendedoras: Aceptan proyectos de alto riesgo.
Empresas de jerarquía rígida: Pueden dificultar la autoridad del Director de

Proyectos.

La Estructura de la Organización Ejecutora
La organización ejecutora puede ser de tres tipos: funcional, matricial y

proyectizada:
Funcional: Organizaciones tradicionales que trabajan en silos separados (e.g.

recursos humanos, contabilidad, producción, marketing, finanzas). Los directores de
proyectos tienen poca autoridad formal, lo que se traduce en dificultades para
conseguir recursos. Suelen reportar a un gerente funcional. Trabajan a tiempo parcial
en el proyecto.
Proyectizada: La mayoría de los empleados trabajan en proyectos. Los

directores de proyectos tienen mucha autoridad y visibilidad.
Matricial: Tiene elementos de las dos anteriores. Pueden ser de 3 tipos:

matricial fuerte, débil y equilibrada. El personal asignado a proyectos suele reportar al
gerente funcional y al director de proyectos. Son débiles o fuertes según el grado de
autonomía, autoridad y recursos disponibles para los Directores de Proyecto.
La siguiente tabla representa el peso de los directores de proyectos según el

tipo de organización ejecutora:
MATRICIAL PROYEC-
FUNCIONAL
Débil Equilibrada Fuerte TIZADA
Poca / Limitad Baja / Moderada Alta /

Autoridad
ninguna a moderada / alta casi total
Disponibilidad Poca / Limitad Baja / Moderada Alta /

de recursos ninguna a moderada / alta casi total
Gerente Director Director

Control del Gerente Combinaci
funcion del del
Presupuesto funcional ón
al proyecto proyecto
Dedicación Parcial Parcial Completa Completa Completa

A continuación se representa el contraste de un organigrama típico en una

organización funcional, frente al organigrama típico en una organización proyectizada:
En una organización funcional no suele haber un director del proyecto

responsable del proyecto. Cuando el proyecto implica a varios departamentos, el
control se reparte entre los gerentes funcionales, que asumen las labores de
coordinación. Las personas involucradas reportan exclusivamente a su responsable
funcional.
Por el contrario, en una organización proyectizada, sí existe la figura del

director de proyectos, que es el máximo responsable del proyecto y tiene autoridad
sobre las personas que configuran su equipo de trabajo.

A continuación se representan los organigramas típicos de las organizaciones

matriciales:
Las organizaciones matriciales tienen un modelo de gestión de proyectos

intermedio: Las personas del equipo siguen reportando a sus gerentes funcionales,
pero además reportan al órgano de coordinación del proyecto. Al contrario que en las
organizaciones funcionales, el control no es asumido por los gerentes funcionales. A
diferencia de las organizaciones proyectizadas, pero las personas del equipo siguen
reportando a sus gerentes funcionales:
En una organización matricial débil no suele haber un director del proyecto

responsable del proyecto. Cuando el proyecto implica a varios departamentos, el
control ya no se reparte entre los gerentes funcionales, como ocurría en las
organizaciones funcionales, sino que el control es asumido dentro del equipo, aunque
no hay un máximo responsable del proyecto y esto plantea problemas de autoridad e
ineficiencia en la toma de decisiones.
Una organización matricial equilibrada se diferencia de una matricial débil en

cuanto a que ya sí existe la figura del Director del Proyecto con responsabilidad y
autoridad, si bien pertenece a un departamento y reporta a su responsable funcional.
Una organización matricial fuerte se diferencia de una matricial equilibrada en

cuanto a que el Director del Proyecto no pertenece a un departamento funcional, y por
lo tanto es más neutral.

Gestion de Proyectos

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Gestion de Proyectos

Caricato da

Copyright:

Formati disponibili

MANUAL

European Open Business School

1. ACTA DE CONSTITUCIÓN E IDENTIFICACIÓN DE INTERESADOS ............................................ 4

European Open Business School 2

7. CONTROL DE CAMBIOS Y ANALISIS DE IMPACTO ............................................................. 219

European Open Business School 3

1. ACTA DE CONSTITUCIÓN E IDENTIFICACIÓN DE

La Gestión de la Integración del Proyecto incluye los procesos y actividades

El significado de la palabra “integración” en Gestión de Proyectos

La palabra “integración” tiene más de un significado en gestión de proyectos.

European Open Business School 4

 Gestión de adquisiciones: En lo que respecta a los trabajos a subcontratar,

En la práctica, la palabra integración puede tener otras acepciones, como son

 El director de proyectos ejerce un rol integrador (centralizador, punto único de

El inicio de un proyecto en una organización

La gestión del proyecto comienza desde antes de su aprobación, cuando es tan

Según la Guía del PMBOK®, los proyectos responden a una necesidad de la

European Open Business School 5

Tipo de Necesidad Ejemplo

Esta información causal puede encontrarse en un documento como es un plan

La decisión de lanzar un proyecto nunca ha de tomarse a la ligera. Antes de

Si el proyecto finalmente se aprueba, debe quedar constancia escrita. Este

En las organizaciones dedicadas a vender proyectos, como las empresas de

Cuando un proyecto se subdivide en varias fases, cada una de ellas podrá

European Open Business School 6

 Mantener el proyecto centrado en la necesidad de negocio.

Valoración financiera de proyectos

 Gestión de la Demanda: La iniciativa es justificada, priorizada, aprobada, etc.;

Como puede apreciarse en la figura, cada disciplina de gestión está

Volvamos al inicio del proyecto. La Guía del PMBOK® no pretende

European Open Business School 7

Cuando el responsable del departamento financiero diga que nuestro proyecto

El primer concepto a tener en cuenta para valorar financieramente un proyecto

El siguiente concepto importante es que el dinero crece con el tiempo. O lo que

European Open Business School 8

Para comparar económicamente dos cantidades en distintos periodos,

Si tenemos varios flujos de caja, positivos o negativos, se calcula el valor actual

Ejercicio 1. Usted tiene un local y se plantea 2 opciones: 1) Si lo vende te

Es recomendable invertir, ya que:

European Open Business School 9

Ejercicio 2. ¿Y si la venta por 400k€ no es segura? ¿Y si tiene tanto riesgo

Otro indicador muy utilizado en la valoración financiera de proyectos es la Tasa

A un interés del 5% en cada periodo, Excel nos permite calcular el VAN=892€.

Si el interés fuera del 10%, VAN=433€.

European Open Business School 10

¿Y si el interés fuera del 16%? Entonces ocurre que VAN=0.

Gráficamente podríamos construir la curva del

En general, un proyecto con un TIR de más de un

En las empresas, suele conocerse el Promedio Ponderado del Coste de

Cuando se trata de decidir un proyecto frente a otro, se escoge el de mayor

European Open Business School 11

Otro indicador que puede tenerse en cuenta al evaluar un proyecto es el

Para calcular el punto de equilibrio, hay que despejar n de esta ecuación:

Venta por Unidad * n = Coste Fijo + Coste Variable por Unidad * n

European Open Business School 12

Ejercicio 4. Supongamos un restaurante con capacidad de 20 mesas, y cada

 Coste Variable por mesa = 18000 / 300 = 60€

Ejercicio 5. Supongamos los siguientes flujos de caja de un proyecto, en una

European Open Business School 13

En resumen, existen algunos modelos económicos bien conocidos para

Imaginemos un equipo de dirección del proyecto que gestiona eficazmente la

Ejercicio 6. Describa cómo gestionó el alcance el equipo de dirección del

1. Inicio, patrocinador, desarrollar el acta de constitución del proyecto.