“Aplicación de las metodologías en las extensiones

del PMBOK para la gestión del proyecto de

migración de tecnologías”

Estudiante: Guillermo Tapia Fernandes

Director: Jaume Mussons Sellés
2
 Dedicado a mis padres,
quienes me apoyaron incondicionalmente,
y nunca perdieron la fe en mí…

3
ÍNDICE GENERAL:

CAPÍTULO 1: INTRODUCCIÓN ............................................................................. 13

1.1 OBJETIVOS: ....................................................................................................... 13
1.2 FUNDAMENTOS: .............................................................................................. 14
CAPÍTULO 2: ESTÁNDAR PRÁCTICO PARA LAS ESTRUCTURAS DE
SUBDIVISIÓN DEL TRABAJO ................................................................................ 16
2.1 INTRODUCCIÓN: .............................................................................................. 16
2.2 DEFINIENDO AL WBS: .................................................................................... 16
2.2.1 Uso de términos comunes:............................................................................ 17
2.2.2 Conceptos: .................................................................................................... 18
2.2.3 La regla del 100%: ........................................................................................ 19
2.2.4 Sumario: ....................................................................................................... 19
2.3 IMPORTANCIA DEL WBS: .............................................................................. 19
2.3.1 Relaciones con otras herramientas: .............................................................. 21
2.3.2 Integración del WBS y uso por otros estándares: ......................................... 23
2.3.3 Sumario: ....................................................................................................... 23
2.4 DEFINIENDO LA CALIDAD DEL WBS: ........................................................ 23
2.4.1 Primer principio de calidad del WBS: .......................................................... 24
2.4.2 Segundo principio de calidad del WBS: ....................................................... 26
2.4.3 Sumario: ....................................................................................................... 26
2.5 CONSIDERACIONES AL CREAR UN WBS:.................................................. 26
2.5.1 Preparando al WBS: ..................................................................................... 26
2.5.2 Factores generales a ser considerados: ......................................................... 29
2.5.3 Opiniones esenciales: ................................................................................... 32
2.5.4 Evaluando la calidad del WBS: .................................................................... 34
2.5.5 Uso continuado del WBS: ............................................................................ 35
2.5.6 WBS para administración de programas y portafolios: ................................ 36
2.5.7 Sumario: ....................................................................................................... 36
CAPÍTULO 3: ESTÁNDAR PRÁCTICO PARA EL ITINERADO ....................... 38
3.1 INTRODUCCIÓN: .............................................................................................. 38
3.1.1 Visión general: .............................................................................................. 38
3.1.2 Propósito: ...................................................................................................... 39
3.2 EL PROCESO DE DESARROLLO DEL ITINERARIO: .................................. 39
3.2.1 El método de itinerado:................................................................................. 41
3.2.2 El itinerario del proyecto: ............................................................................. 42

4
 3.2.3 Mantenimiento:............................................................................................. 42
3.3 VISIÓN GENERAL DE LAS BUENAS PRÁCTICAS DEL MODELO DE
ITINERARIO: ............................................................................................................ 43
3.3.1 Diseño del modelo de itinerario: .................................................................. 43
3.3.2 Elementos del desarrollo de un buen itinerario: ........................................... 44
3.4 COMPONENTES DEL ITINERADO: ............................................................... 51
3.4.1 Cómo utilizar la lista de componentes:......................................................... 51
3.5 ÍNDICE DE CONFORMIDAD: ......................................................................... 53
3.5.1 Proceso de evaluación de la conformidad: ................................................... 53
CAPÍTULO 4: ESTÁNDAR PRÁCTICO PARA LA GESTIÓN DE LA
CONFIGURACIÓN DEL PROYECTO .................................................................... 55
4.1 INTRODUCCIÓN: .............................................................................................. 55
4.1.1 Propósito del estándar para PCM: ................................................................ 55
4.1.2 Cómo utilizar este estándar: ......................................................................... 55
4.1.3 ¿Por qué aplicar el PCM?: ............................................................................ 55
4.1.4 Puntos clave: ................................................................................................. 57
4.2 PLANIFICACIÓN DE LA ADMINISTRACIÓN DE CONFIGURACIÓN: .... 57
4.2.1 Organización:................................................................................................ 58
4.2.2 Comunicaciones: .......................................................................................... 59
4.2.3 Entrenamiento: ............................................................................................. 60
4.2.4 Gestión de configuración y PCM: ................................................................ 60
4.3 IDENTIFICACIÓN DE LA CONFIGURACIÓN: ............................................. 60
4.3.1 Artefactos del proyecto:................................................................................ 60
4.3.2 Estructura: ..................................................................................................... 61
4.3.3 Identificación de elementos: ......................................................................... 62
4.3.4 Esquema de taxonomía: ................................................................................ 62
4.4 GESTIÓN DE CAMBIOS DE LA CONFIGURACIÓN: ................................... 63
4.4.1 Identificación: ............................................................................................... 64
4.4.2 Proceso: ........................................................................................................ 64
4.4.3 Control: ......................................................................................................... 66
4.4.4 Revisión y aprobación: ................................................................................. 66
4.4.5 Implementación: ........................................................................................... 66
4.4.6 Verificación y Aceptación: ........................................................................... 67
4.4.7 Cierre: ........................................................................................................... 67
4.5 MEDICIONES Y REVISIÓN DEL ESTATUS DE LA CONFIGURACIÓN: .. 67
4.5.1 Depósito de información: ............................................................................. 67
4.5.2 Reporte: ........................................................................................................ 68
4.5.3 Análisis: ........................................................................................................ 70
5
 4.6 VERIFICACIÓN Y REVISIÓN DE LA CONFIGURACIÓN: ......................... 70
4.6.1 Verificación: ................................................................................................. 70
4.6.2 Revisión: ....................................................................................................... 70
4.6.3 Actividades de verificación y revisión: ........................................................ 71
CAPÍTULO 5: ESTÁNDAR PRÁCTICO PARA LA GESTIÓN DE RIESGOS
DEL PROYECTO ........................................................................................................ 72
5.1 INTRODUCCIÓN: .............................................................................................. 72
5.1.1 Factores de éxito críticos para la gestión de riesgos: ................................... 73
5.2 PRINCIPIOS Y CONCEPTOS: .......................................................................... 74
5.2.1 Riesgos individuales y riesgo global del proyecto: ...................................... 74
5.2.2 Posturas del patrocinador ante el riesgo: ...................................................... 75
5.2.3 Proceso iterativo: .......................................................................................... 75
5.2.4 Comunicación: .............................................................................................. 75
5.2.5 Responsabilidad para la gestión de riesgos: ................................................. 76
5.2.6 Rol del administrador del proyecto en la gestión de riesgos: ....................... 76
5.3 INTRODUCCIÓN A LOS PROCESOS DE GESTIÓN DE RIESGOS:............ 77
5.3.1 Procesos de gestión de riesgos: .................................................................... 77
5.4 PLANIFICACIÓN DE LA GESTIÓN DE RIESGOS: ....................................... 79
5.4.1 Factores críticos para el éxito del proceso de gestión de riesgos: ................ 81
5.4.2 Técnicas y herramientas para el proceso de gestión de riesgos:................... 82
5.4.3 Documentando los resultados del proceso de gestión de riesgos: ................ 82
5.5 IDENTIFICACIÓN DE RIESGOS: .................................................................... 83
5.5.1 Factores críticos de éxito para el proceso de identificación de riesgos: ....... 83
5.5.2 Técnicas y herramientas para el proceso de identificación de riesgos: ........ 84
5.5.3 Documentando los resultados del proceso de identificación de riesgos: ..... 85
5.6 ANÁLISIS CUALITATIVO DE RIESGOS: ...................................................... 85
5.6.1 Factores críticos de éxito para el proceso de análisis cualitativo de riesgos: 86
5.6.2 Técnicas y herramientas para el proceso de análisis cualitativo de riesgos: 87
5.7 ANÁLISIS CUANTITATIVO DE RIESGOS: ................................................... 88
5.7.1 Factores críticos de éxito para el proceso de análisis cuantitativo de riesgos:
................................................................................................................................ 90
5.7.2 Técnicas y herramientas para el proceso de análisis cuantitativo de riesgos:
................................................................................................................................ 91
5.7.3 Documentando los resultados del proceso de análisis cuantitativo de riesgos:
................................................................................................................................ 92
5.8 PLANIFICACIÓN DE RESPUESTAS: ............................................................. 92
5.8.1 Factores críticos de éxito para el proceso de planificación de respuestas: ... 93
5.8.2 Estratégicas de respuestas:............................................................................ 94

6
 5.8.3 Técnicas y herramientas para el proceso de planificación de respuestas: .... 95
5.8.4 Documentar los resultados del proceso de planificación de repuestas: ........ 96
5.9 MONITOREO Y CONTROL DE RIESGOS: .................................................... 97
5.9.1 Factores críticos para el éxito del proceso de monitoreo y control de riesgos:
................................................................................................................................ 98
5.9.2 Técnicas y herramientas para el proceso de monitoreo y control de riesgos:
................................................................................................................................ 99
5.9.3 Documentar los resultados del proceso de monitoreo y control de riesgos:
.............................................................................................................................. 100
CAPÍTULO 6: ESTÁNDAR PRÁCTICO PARA LA GESTIÓN DEL VALOR
OBTENIDO................................................................................................................. 101
6.1 INTRODUCCIÓN: ............................................................................................ 101
6.2 TÉCNICAS DEL EVM: .................................................................................... 103
6.3 ANÁLISIS Y PREDICCIÓN CON EL EVM: .................................................. 104
6.4 GUÍA PARA EL USO DE TÉCNICAS CLAVES DE EVM: .......................... 107
CAPÍTULO 7: PRESENTACIÓN DEL CASO PRÁCTICO DE APLICACIÓN 111
CAPÍTULO 8: GRUPO DE PROCESOS DE INICIACIÓN ................................. 114
8.1 INTRODUCCIÓN: ............................................................................................ 114
8.2 ACTA DEL PROYECTO: ................................................................................ 114
8.2.1 Definición: .................................................................................................. 114
8.2.2 Objetivos: ................................................................................................... 114
8.2.3 Personal: ..................................................................................................... 115
8.2.4 Organización:.............................................................................................. 116
8.2.5 Presupuesto: ................................................................................................ 116
8.2.6 Riesgos: ...................................................................................................... 117
8.3 ALCANCE PRELIMINAR DEL PROYECTO: ............................................... 118
8.3.1 Alcance: ...................................................................................................... 118
8.3.2 Calendario: ................................................................................................. 118
8.3.3 Entregables: ................................................................................................ 119
CAPÍTULO 9: GRUPO DE PROCESOS DE PLANIFICACIÓN ........................ 121
9.1 DEFINICIÓN DE LA ESTRUCTURA DE SUDIVISIÓN DEL TRABAJO: . 121
9.1.1 Concepción del WBS: ................................................................................ 121
9.1.2 Subdivisión principal: ................................................................................. 122
9.1.3 Tipos de migración: .................................................................................... 123
9.1.4 Subdivisiones secundarias: ......................................................................... 126
9.2 GESTIÓN DE RECURSOS Y TIEMPO EN EL PROYECTO: ...................... 128
9.2.1 Listado de recursos: .................................................................................... 128
9.2.2 Asignación de recursos a las actividades principales: ................................ 129

7
 9.2.3 Asignación de recursos por tipos de migración:......................................... 129
9.2.4 Asignación de recursos a las actividades secundarias: ............................... 132
9.2.5 Secuenciado y duración de las actividades principales: ............................. 133
9.2.6 Secuenciado y duración de las actividades por tipos de migración:........... 134
9.2.7 Secuenciado y duración de las actividades secundarias: ............................ 137
9.2.8 Cronograma del proyecto: .......................................................................... 139
9.2.9 Camino crítico: ........................................................................................... 141
9.2.10 Tiempo adicional del proyecto: ................................................................ 142
9.3 GESTIÓN DE COSTOS Y PRESUPUESTO DEL PROYECTO: ................... 143
9.3.1 Asignación de costos a las actividades principales: ................................... 143
9.3.2 Asignación de costos por tipos de migración: ............................................ 143
9.3.3 Asignación de costos a las actividades secundarias: .................................. 146
9.3.4 Línea base del presupuesto: ........................................................................ 147
9.3.5 Presupuesto adicional del proyecto: ........................................................... 149
9.4 GESTIÓN DE RIESGOS EN EL PROYECTO:............................................... 149
9.4.1 Planificación de la gestión de riesgos:........................................................ 149
9.4.2 Identificación de riesgos: ............................................................................ 153
9.4.3 Análisis cualitativo de los riesgos: ............................................................. 156
9.4.4 Análisis cuantitativo de los riesgos: ........................................................... 162
9.4.5 Planificación de respuestas: ........................................................................ 166
CAPÍTULO 10: SIMULACIÓN DE EJECUCIÓN ................................................ 172
10.1 INTRODUCCIÓN: .......................................................................................... 172
10.2 GENERACIÓN DE LA SIMULACIÓN: ....................................................... 172
10.2.1 Información previa: .................................................................................. 172
10.2.2 Presentación de los resultados: ................................................................. 173
10.3 ANÁLISIS DE LOS RESULTADOS: ............................................................ 174
10.3.1 Análisis general de los resultados:............................................................ 174
10.3.2 Análisis temporal de los resultados: ......................................................... 177
10.3.3 Análisis presupuestal de los resultados: ................................................... 181
10.4 GESTIÓN DEL VALOR OBTENIDO: .......................................................... 184
10.4.1 Presentación de los elementos básicos del EVM: .................................... 184
10.4.2 Análisis del desempeño con EVM: .......................................................... 186
10.4.3 Predicción del desarrollo con EVM: ........................................................ 187
CAPÍTULO 11: CONCLUSIONES .......................................................................... 190
CAPÍTULO 12: LÍNEAS FUTURAS ....................................................................... 193
BIBLIOGRAFÍA ........................................................................................................ 195
GLOSARIO................................................................................................................. 196

8
 1. INCLUSIONES Y EXCLUSIONES:.................................................................. 196
2. SIGLAS COMUNES: ......................................................................................... 196
3. DEFINICIONES: ................................................................................................ 198
ANEXO A: DOCUMENTACIÓN DEL CASO DE MIGRACIÓN DE
TECNOLOGÍAS: ....................................................................................................... 243
A.1 INTRODUCCIÓN A LAS REDES HFC: ........................................................ 243
A.2 DESCRIPCIÓN FUNCIONAL DE LA RED HFC: ........................................ 244
A.3 DIMENSIONADO DE LA RED HFC: ............................................................ 246
A.4 TÉCNICAS DE MEJORA: .............................................................................. 249
A.4.1 Fibra óptica dedicada: ................................................................................ 249
A.4.2 Técnicas de reutilización del canal de retorno:.......................................... 250
A.5 GESTIÓN Y MANTENIMIENTO: ................................................................. 252
A.5.1 Gestión: ...................................................................................................... 253
A.5.2 Mantenimiento: .......................................................................................... 253

9
ÍNDICE DE GRÁFICOS:

Gráfico 1: Conformación de los Control Accounts ...................................................... 102

Gráfico 2: Red HFC ...................................................................................................... 111
Gráfico 3: Red SDH ..................................................................................................... 112
Gráfico 4: Red por zonas .............................................................................................. 112
Gráfico 5: Organigrama del área de red del operador .................................................. 113
Gráfico 6: Estructura de subdivisión organizacional.................................................... 116
Gráfico 7: Duración del proyecto por fases .................................................................. 119
Gráfico 8: Lógica para determinar el tipo de migración .............................................. 124
Gráfico 9: Fechas planificadas de inicio y fin de las actividades ................................. 140
Gráfico 10: Cronograma planificado de las actividades ............................................... 141
Gráfico 11: Camino crítico del proyecto ...................................................................... 142
Gráfico 12: Flujo semanal de los gastos planificados del proyecto ............................. 148
Gráfico 13: Línea base de medición de los gastos ....................................................... 149
Gráfico 14: Estructura de subdivisión de los riesgos teórica ....................................... 153
Gráfico 15: Distribución de percentiles de la duración total en horas.......................... 164
Gráfico 16: Distribución de percentiles del presupuesto en euros ............................... 165
Gráfico 17: Fechas, duraciones y costos de las actividades simuladas ........................ 173
Gráfico 18: Flujo de gastos semanales de la simulación .............................................. 175
Gráfico 19: Diferencia de gastos semanales simulados respecto a planificados .......... 176
Gráfico 20: Evolución de los gastos totales de la simulación ...................................... 177
Gráfico 21: Duraciones planificadas y resultantes de las tareas simuladas .................. 179
Gráfico 22: Acumulado de duraciones por tareas simuladas ....................................... 180
Gráfico 23: Gastos planificados y resultantes de las tareas simuladas ......................... 182
Gráfico 24: Acumulado de gastos por tareas simuladas ............................................... 183
Gráfico 25: Comparación del desarrollo del proyecto respecto a la línea base ............ 185
Gráfico 26: Estructura básica de red HFC .................................................................... 243
Gráfico 27: Estructura segmentada de red HFC ........................................................... 243
Gráfico 28: Frecuencias de subida y bajada para HFC en Europa ............................... 244
Gráfico 29: Esquema de la bidireccionalidad de la red HFC ....................................... 245
Gráfico 30: Red HFC para telefonía ............................................................................. 247
Gráfico 31: Red HFC para acceso a internet ................................................................ 248
Gráfico 32: Red HFC para video bajo demanda .......................................................... 248
Gráfico 33: Frecuencias para Broadcast y Narrowcast de HFC ................................... 248
Gráfico 34: Multiplexación por división en el tiempo en el canal de retorno .............. 250
Gráfico 35: Conexión directa desde nodos hasta cabecera en el canal ascendente ...... 250
Gráfico 36: Filtrado previo de señales en el canal de retorno ...................................... 251
Gráfico 37: Esquema general del canal de retorno ....................................................... 251
Gráfico 38: Recepción de señales en la cabecera ......................................................... 251
Gráfico 39: Utilización de multiplexores ópticos en el canal de retorno ..................... 252

10
ÍNDICE DE TABLAS:

Tabla 1: Métodos de creación del WBS ......................................................................... 28

Tabla 2: Niveles de uso del WBS ................................................................................... 36
Tabla 3: Formato para componentes .............................................................................. 51
Tabla 4: Ejemplo de componentes #1 ............................................................................ 52
Tabla 5: Ejemplo de componentes #2 ............................................................................ 52
Tabla 6: Ejemplo de componentes #3 ............................................................................ 52
Tabla 7: Análisis de efectos del PCM ............................................................................ 56
Tabla 8: Elementos del PCM .......................................................................................... 59
Tabla 9: Áreas clave de enfoque para la gestión de riesgos ........................................... 82
Tabla 10: Comparación análisis cualitativo y cuantitativo............................................. 90
Tabla 11: Subdivisión principal de actividades ............................................................ 123
Tabla 12: Actividades de la migración directa ............................................................. 125
Tabla 13: Actividades de la migración con ampliación ............................................... 125
Tabla 14: Actividades de la migración con construcción ............................................. 126
Tabla 15: Actividades de la primera fase ..................................................................... 127
Tabla 16: Actividades de la segunda fase..................................................................... 127
Tabla 17: Actividades de la tercera fase ....................................................................... 128
Tabla 18: Estructura de subdivisión de los recursos .................................................... 129
Tabla 19: Recursos para las actividades principales .................................................... 129
Tabla 20: Recursos para la migración directa .............................................................. 130
Tabla 21: Recursos para la migración con ampliación ................................................. 131
Tabla 22: Recursos para la migración con construcción .............................................. 132
Tabla 23: Recursos para la primera fase ....................................................................... 132
Tabla 24: Recursos para la segunda fase ...................................................................... 133
Tabla 25: Recursos para la tercera fase ........................................................................ 133
Tabla 26: Secuenciado y duraciones de las actividades principales............................. 134
Tabla 27: Secuenciado y duraciones de la migración directa ....................................... 135
Tabla 28: Secuenciado y duraciones de la migración con ampliación ......................... 136
Tabla 29: Secuenciado y duraciones de la migración con construcción ...................... 137
Tabla 30: Secuenciado y duraciones de la primera fase ............................................... 138
Tabla 31: Secuenciado y duraciones de la segunda fase .............................................. 138
Tabla 32: Secuenciado y duraciones de la tercera fase ................................................ 139
Tabla 33: Costos de las actividades principales ........................................................... 143
Tabla 34: Costos de la migración directa ..................................................................... 144
Tabla 35: Costos de la migración con ampliación........................................................ 145
Tabla 36: Costos de la migración con construcción ..................................................... 146
Tabla 37: Costos de la primera fase ............................................................................. 146
Tabla 38: Costos de la segunda fase ............................................................................. 147
Tabla 39: Costos de la tercera fase ............................................................................... 147
Tabla 40: Asignación de recursos a los riesgos ............................................................ 156
Tabla 41: Estructura de subdivisión de riesgos práctica .............................................. 157
Tabla 42: Probabilidad de ocurrencia de los riesgos .................................................... 158
Tabla 43: Nivel de impacto de los riesgos .................................................................... 159
Tabla 44: Matriz de probabilidad e impacto de los riesgos .......................................... 160
Tabla 45: Clasificación de los riesgos por prioridad .................................................... 161
Tabla 46: Distribución de percentiles de la duración total en horas ............................. 164
Tabla 47: Distribución de percentiles del presupuesto en euros .................................. 165

11
Tabla 48: Recursos y costos de los riesgos de alta prioridad ....................................... 170
Tabla 49: Gastos semanales de la simulación .............................................................. 175
Tabla 50: Gastos semanales acumulados de la simulación .......................................... 176
Tabla 51: Duraciones planificadas y resultantes de las tareas simuladas ..................... 179
Tabla 52: Gastos planificados y resultantes de las tareas simuladas ............................ 182

12
CAPÍTULO 1: INTRODUCCIÓN

1.1 OBJETIVOS:

Actualmente el mundo empresarial se encuentra inmerso en una constante evolución y

renovación de sus metodologías para el logro cada vez más óptimo y beneficioso de sus
objetivos. En este aspecto, lo que se busca siempre es la minimización de los gastos, el
aumento de los rendimientos y beneficios, y la más óptima utilización de los tiempos,
con la mira puesta en el crecimiento y la competitividad. Un claro ejemplo de esta
dinámica es el sector de las telecomunicaciones, en el cual además la constante
renovación y apuesta por nuevas tecnologías son una prioridad para unas empresas que
están acostumbradas a ofrecer una imagen de vanguardia y modernidad.

Para poner en funcionamiento las acciones e ideas que mantienen y mejoran las
prestaciones de las empresas en diversos aspectos, el modelo más común seguido
actualmente es la obtención de objetivos a través de la ejecución de proyectos. Es por
ello que la gestión de proyectos es un ámbito que ha evolucionado bastante desde sus
inicios hasta convertirse en un pilar fundamental para organizar integralmente la forma
de trabajo en las empresas.

Es con esta motivación con la que surgió la idea de realización del presente Proyecto de
Final de Carrera, en el cual su desarrollo fue propuesto con la finalidad de poder
alcanzar los siguientes objetivos:
• El primer objetivo es el estudio y síntesis de los cinco nuevos libros publicados
sobre las extensiones del libro del PMBOK para la gestión de proyectos. Cada
libro publicado se adentra en un aspecto diferente de la gestión, presentando
nuevas definiciones, herramientas y metodologías útiles para la planificación,
ejecución y control de proyectos, tomando en cuenta aspectos minuciosos para
no dejar escapar detalles importantes.
• Para cumplir el segundo objetivo se tratará de aplicar los nuevos conocimientos
estudiados a un proyecto real del sector de las telecomunicaciones, para analizar
la viabilidad y aplicabilidad de dichas extensiones. La aplicación se basará
principalmente en las fases de iniciación, planificación y ejecución del proyecto,
utilizando las principales metodologías propuestas y analizando los resultados
obtenidos.
• Como tercer y último objetivo se plantea la revisión de los análisis y resultados
obtenidos anteriormente en la aplicación, para la extracción de conclusiones
sobre las extensiones y un balance general sobre cuál fue su utilidad real en este
proyecto. Se plantea además la mención de los posibles puntos fuertes y débiles
de las metodologías aplicadas para resaltar lo más útil, identificar aspectos
mejorables en caso de haberlos, y tener una idea de hacia dónde apunta la
tendencia de la gestión de proyectos en un futuro.

Por encima de todos estos objetivos mencionados, la principal idea de este Proyecto de
Final de Carrera es que tú, estimado lector, puedas entender los fundamentos sobre los
que se basa la gestión de proyectos y sus respectivas extensiones, y veas además su
utilidad real en la planificación de un proyecto del sector de las telecomunicaciones.

13
1.2 FUNDAMENTOS:

Un proyecto se define como todo aquel esfuerzo temporal que es llevado a cabo para la
creación de un producto, servicio o resultado único. Todos los proyectos tienen una
causa por la que se realizan, y una finalidad concreta que es el alcance de unos
objetivos. Un proyecto se define como esfuerzo temporal porque tiene una finalización
que ocurrirá cuando se alcancen dichos objetivos, cuando se determine que los objetivos
no se podrán alcanzar, o cuando deja de existir la causa por la que se inició. Un
proyecto es capaz de realizar como objetivos:
• La generación de un producto, ya sea final, o un componente de otro elemento.
• El ofrecimiento de servicios, que cumplan con una serie de características.
• La generación de documentos o entregables, lo cuales pueden ser productos de
una investigación y/o desarrollo estructurado.

La gestión de proyectos se define entonces como la aplicación de habilidades,

conocimientos, herramientas, técnicas y estrategias a las actividades de un proyecto para
poder alcanzar los objetivos. Dicha gestión de proyecto divide el trabajo a realizar en
una serie de procesos, los cuales son lógicamente integrados en los 5 grupos de procesos
que están dados por la iniciación, planificación, ejecución, control y seguimiento, y
finalización. La administración de un proyecto pasa por identificar requisitos y
necesidades, manejar las expectativas de los interesados en el proyecto, y saber
organizar, gestionar e integrar todos los aspectos del proyecto. Dichos aspectos están
conformados por el alcance, cronograma, presupuesto, calidad, recursos humanos,
comunicación, riesgos y adquisiciones. Cada aspecto puede tener sus respectivas
limitaciones, y es responsabilidad de los administradores del proyecto el saber
relacionar y equilibrar todos estos detalles al momento de realizar la planificación.

El primer paso para el éxito de un proyecto pasa necesariamente por una planificación al
detalle del trabajo a realizar. La filosofía establecida es la del ‘divide y vencerás’, dado
que en un proyecto la carga de trabajo a realizar es siempre elevada como para
realizarse directamente. Entonces es vital la definición del alcance en términos de
entregables, para que luego éstos sean descompuestos en partes más manejables. La
descomposición del trabajo implica un balance entre nivel de detalle y facilidad para el
control. Implica además una necesaria estructuración y relación entre los componentes
generados por la división, y siempre buscando que el principal objetivo sea facilitar la
consecución de los entregables, para dar sentido a la división. Otro factor importante es
la designación de los tiempos, fechas y sucesión entre las actividades para poder saber
cuál será el calendario del proyecto y sus fases. Dado que la mayor parte de los
proyectos nunca terminan ejecutándose exactamente de la manera planificada, el
proceso de programación de tiempos se debe ir adaptando a la evolución del proyecto y
de los factores que lo van afectado. La idea es que la programación del proyecto pueda
proveer una ‘hoja de ruta’ que revele cuándo y cómo se alcanzarán los objetivos.

La realización de una planificación implica la realización de ciertas estimaciones de

futuro, que de por sí conlleva a trabajar con un cierto nivel de incertidumbre en
diferentes aspectos que implican riesgos. Un riesgo se define como un evento o
condición inciertos que de ocurrir, puede tener un impacto positivo o negativo en la
consecución de los objetivos del proyecto. Es por ello que se deberá intentar trabajar a
un nivel de máximo detalle, para minimizar (o maximizar) en la medida de lo posible
dichos riesgos, y además tener en cuenta acciones y estrategias para gestionarlos. De

14
todas maneras en la mayoría de los proyectos siempre ocurren elementos no
planificados que terminan produciendo desviaciones y de ser significativas se deberán
aplicar planes de contingencia. Por las mismas razones, una planificación exhaustiva y
detallada casi nunca es suficiente para garantizar que el proyecto alcanzará sus
objetivos, por lo que se hacen necesarios los mecanismos de control y seguimiento de la
ejecución en la gestión del proyecto. Su rendimiento mejora notablemente cuando se
introduce la retroalimentación de datos sobre el proyecto para controlar su evolución,
tomar medidas, y predecir su futuro. A esta gestión se le conoce como ‘gestión con
luces encendidas’, y consiste en la elaboración de una línea base de seguimiento en la
planificación que sirva de guía sobre la que se pueda medir el trabajo y los gastos
realizados, el tiempo empleado, y hacer estimaciones a futuro.

En el presente Proyecto de Final de Carrera se utilizarán únicamente las metodologías

más convenientes de las que se expondrán en los capítulos teóricos a continuación para
la planificación del proyecto de migración. También se dará mayor énfasis a las áreas de
conocimiento de alcance, tiempo, presupuesto, recursos humanos y riesgos.

15
CAPÍTULO 2: ESTÁNDAR PRÁCTICO PARA LAS
ESTRUCTURAS DE SUBDIVISIÓN DEL TRABAJO

2.1 INTRODUCCIÓN:

El Work Breakdown Structure (WBS) es una herramienta que sirve para ayudar a
definir el trabajo que se debe de realizar en un proyecto de forma consistente y
ordenada, estableciendo un esquema de desarrollo a partir de toda la información
detallada que se pueda obtener sobre el trabajo a realizar y los objetivos. El WBS ayuda
a suplir la necesidad de control del proyecto según el nivel de detalle que se utilice, en
el cual el proyecto es representado en una serie de objetivos que a su vez se pueden
descomponer en partes menores; esta descomposición es capaz de determinar el ciclo de
vida del proyecto en función del método con el que se fragmente el trabajo. Provee
también al personal que trabaja en el proyecto un marco que sirve de base con la que se
podrá diagnosticar el estado del avance y hacer reportes.

El uso del WBS no únicamente está vinculado al ámbito interno de la empresa, ya que
es de mucha utilidad para facilitar la entrega de información a las personas o entidades
externas con intereses en el proyecto, también denominados Stakeholders; se suele
combinar el esquema del WBS con información adicional para enviar reportes e
informes de costos, alcances, riesgos, entre otros. Otra de las utilidades que tiene el
WBS es que aporta mucha flexibilidad al proyecto porque una vez se han definido sus
características, éstas son requeridas por otros procesos como información de entrada,
por ejemplo la realización de diagramas de red de procesos del proyecto, asignación de
tareas a equipos de trabajo, reportes de desempeño por tareas, etc.

En el análisis del WBS se definen tres tipos de proyectos, que son los de enfoque
interno, externo o de ambos. Un proyecto de enfoque interno es uno que produce
resultados que serán utilizados por otras fases del proyecto, equipos u organizaciones
dentro de la que se encarga del proyecto, mientras que un proyecto con enfoque externo
produce resultados para clientes, u organizaciones externas. El tercer tipo de proyecto
es el que comprende los enfoques tanto interno como externo, y produce resultados para
ambas partes; los resultados se pueden concebir tanto como productos, servicios o
logros de objetivos, y en cualquiera de los tres casos será indispensable la aplicación del
WBS para el desarrollo del proyecto. Cuando se hace la definición del WBS de un
proyecto en la fase de planificación, ésta no es definitiva, porque es realizada con la
información inicial que se tiene al alcance, y siempre se ajustará a los cambios que se
hagan en los alcances del proyecto a través de los procesos de control; dichas
actualizaciones se conocen como Elaboraciones Progresivas.

2.2 DEFINIENDO AL WBS:

Como concepto elemental de la estructura de subdivisión del trabajo o WBS, se puede

decir que es una herramienta de gestión que define el alcance total del proyecto y divide
el trabajo a realizar en partes más pequeñas y manejables denominadas paquetes de
trabajo o Work Packages, y a las cuales se puede sondear, estimar, organizar y
controlar. El WBS facilita la administración de proyecto al subdividir y distribuir el
trabajo de manera estructurada, de manera que permite la consecución de los resultados
16
de forma ordenada, ya sea ejecutándose de manera serial, paralela, o como se determine
en el diagrama de tareas, y a su vez facilita el trabajo de otros procesos como el de
asignación de recursos, itinerado, medición, análisis de riesgos y control del proyecto.

2.2.1 Uso de términos comunes:

Para poder estudiar y comprender el uso del WBS, es necesario tener en cuenta una
serie de términos que se utilizan con mucha frecuencia, y a continuación de hace la
definición de cada uno de ellos:
• Trabajo: Esfuerzo sostenible física o psicológicamente, o ejercicio de habilidad
para superar obstáculos y alcanzar un objetivo. Comúnmente utilizado para
hacer referencia a una específica actividad, deber o función a menudo parte o
fase de una tarea mayor. En el contexto del presente libro, el trabajo se referirá a
objetivos y alcances concretos conseguidos a costa de un esfuerzo, y no del
esfuerzo en sí.
• Subdivisión: Descomposición, separación en sustancias más simples o división
en partes o categorías.
• Estructura: Algo ordenado siguiendo un determinado patrón de organización.

Cabe hacer mención que el WBS se basa en todo tipo de trabajo a realizar para alcanzar
objetivos tangibles y conforma una jerarquía de objetivos concretos o ‘entregables’ que
están organizadas en relaciones del tipo ‘padre-hijo’. En este caso se puede decir que el
WBS es una especie de estructura de subdivisión de entregables, y maneja una serie de
términos relacionados que se definen a continuación:
• Entregable: Cualquier producto, resultado o resultado único y verificable capaz
de desempeñar un servicio que debe ser producido para completar un proceso,
fase o proyecto. Generalmente utilizado más rigurosamente en referencia a un
entregable externo, el cual está sujeto a ser aprobado por el patrocinador o
cliente.
• Orientado: Alineado o posicionado con respecto a un punto o marco de
referencia, enfocado hacia asuntos e intereses de un grupo específico.
• Jerárquico: Clasificado de acuerdo a diversos criterios en sucesivos niveles o
capas.
• Descomposición: Una técnica de planificación que subdivide al alcance y
objetivos del proyecto en componentes más pequeños y manejables, hasta que el
trabajo asociado a conseguir los alcances del proyecto y entregables sea definido
en detalle suficiente para soportar ejecución, monitoreo y control del trabajo.

La lista de términos que se definen a continuación son conceptos relacionados con el rol
integral que el WBS ejerce en la administración de proyectos:
• Actividad: Un componente de trabajo realizado durante el curso del proyecto.
• Esfuerzo repartido: Es todo esfuerzo aplicado al trabajo del proyecto que no es
directamente visible, en esfuerzos discretos para ese trabajo, pero el cual está
relacionado directamente a esfuerzos de trabajos discretos y medibles. Contrasta
con el esfuerzo discreto.
• Cuenta de control: Más conocido como Control Account, es un punto de control
de gestión en donde el alcance, presupuesto, costo actual e itinerario son
integrado y comparados a los Earned Values para mediciones de desempeño.
Las Control Accounts son ubicadas en puntos de gestión seleccionados del
WBS. Cada Control Account deberá incluir uno o más paquetes de trabajo, pero
17
 cada paquete de trabajo debe ser asociado únicamente a un Control Account.
Cada Control Account es relacionado con un solo componente organizacional
específico en la OBS.
• Esfuerzo discreto: El esfuerzo de trabajo es separado, distinguido y relacionado
a la finalización de entregables y componentes de WBS específicos, y puede ser
directamente planificado y medido. Contrasta con el esfuerzo repartido.
• Nivel de esfuerzo: También denominado Level of Effort (LOE), es una actividad
de soporte que no produce resultados definitivos. Es caracterizado generalmente
por un ritmo uniforme de desempeño sobre un periodo de tiempo determinado
por las actividades a las que da soporte.
• Tarea: Es un término para un trabajo del cual su significado y ubicación dentro
de un plan estructurado para el trabajo de un proyecto varía con el área de
aplicación, industria, y el tipo de software de gestión de proyectos.
• Componente de WBS: Una entrada en el WBS que puede estar a cualquier nivel.
• Paquete de trabajo: Un componente de trabajo del proyecto o entregable del más
bajo nivel de cualquier rama de la jerarquía del WBS. Incluye las actividades de
itinerario y programas de itinerario requeridos para completar el entregable del
paquete de trabajo.
• Elemento de WBS: Cualquier componente único de WBS y sus atributos de
WBS asociados contenidos dentro de un WBS individual.

2.2.2 Conceptos:

En líneas generales, el WBS produce una visión más clara del trabajo y los resultados
del proyecto, divide el trabajo en paquetes de trabajo más jerarquizados y manejables,
que suple las necesidades de control generando un nivel apropiado de data detalla. Los
niveles más bajos del WBS brindan información más detallada del proyecto que es muy
útil a otros procesos, ya sean la comunicación con los patrocinadores o clientes,
controles de riesgos y administración. Los niveles más altos de la jerarquía son los que
reflejan las partes principales del trabajo, proveen de un buen enfoque a groso modo del
desempeño de las tareas en el proyecto, y son un paso intermedio para hacer sondeos de
avances por partes o secciones, entre las tareas individuales y del proyecto en general.
En resumen, si el WBS de un proyecto está estructurado de una manera coherente con
las características del mismo, hará a que la gestión se haga de una manera más rápida y
fácil de identificar, a la misma vez que ayudará a los patrocinadores o clientes a que
tengan un mejor y más claro entendimiento del avance y puedan confiar en que los
objetivos se terminarán alcanzando.

El Work Breakdown Structure sienta las bases para poder integrar los paquetes de
trabajo y los objetivos intermedios con todos los demás aspectos de las fases del
proyecto, que son iniciación, planificación, ejecución, control y finalización. En este
sentido, un WBS orientado a los entregables genera beneficios al proyecto, como una
mejor comunicación entre los patrocinadores, clientes y los que trabajan en el proyecto,
mediciones más detalladas y precisas sobre las tareas, riesgos y costos, la seguridad de
que la totalidad del trabajo a realizar es identificado e incluido, y por último las bases
para un correcto control de los avances en el proyecto.

Si el WBS que se aplica a un proyecto está bien diseñado, puede llegar a ser la
herramienta fundamental sobre la que se realiza la gestión, dado que aporta una gran
variedad de datos en diferentes niveles de detalle, formatos y estructuras; provee tanto

18
representaciones gráficas como resúmenes textuales del avance realizado. El WBS
define el trabajo en términos de entregables de manera que no sólo los participantes sino
también los patrocinadores y clientes puedan entender, soporta la documentación de la
contabilidad, y que los entregables tengan responsables a cargo, gracias a que cada
elemento del WBS tiene a cargo una unidad del OBS, tal y como se define en la matriz
de asignación de responsabilidades o Responsibility Assignment Matrix (RAM).
También soporta el seguimiento de los riesgos, para que el administrador del proyecto
pueda identificarlos y preparar las respuestas necesarias.

2.2.3 La regla del 100%:

La regla del 100% es una de las más importantes que utiliza el Work Breakdown
Structure para su establecimiento y aplicación en un proyecto dado. Esta regla dicta que
desde absolutamente todos los puntos de vista, la suma de los trabajos y objetivos
parciales tiene que corresponder exactamente con el trabajo y objetivos principales, de
manera que esta suma no sea menor pero tampoco mayor, y en ella se deben incluir no
únicamente los objetivos internos, externos e intermedios, sino también el trabajo extra
a realizar como es el administrativo y de soporte. La regla se aplica a su vez a las
relaciones ‘padre-hijo’ que hay en la jerarquía del WBS, haciendo que la sumatoria de
trabajos que hay en un nivel de la estructura del WBS sea la misma que el trabajo del
nivel superior del cual estos trabajos inferiores se subdividen. A nivel de paquete de
trabajo, la regla del 100% se aplica como la igualdad que debe de haber entre la lista de
actividades en un paquete de trabajo y el trabajo necesario para completar el mismo
paquete de trabajo.

Cuando se realiza la subdivisión del trabajo del proyecto para dar forma a la estructura
del WBS, ésta se debe de realizar siempre en función de las características propias que
pueda presentar el proyecto y el entorno, y por ello no necesariamente se deberán
dividir todos los fragmentos del trabajo hasta el último nivel de la jerarquía, ya que
muchas veces puede resultar innecesario e inclusive absurdo.

2.2.4 Sumario:

El definitiva, el WBS sirve para:

• Definir la jerarquía de los entregables.
• Soportar la definición de todo tipo de trabajo requerido para alcanzar los
objetivos o entregables.
• Proveer una representación gráfica o resumen textual del alcance del proyecto.
• Proveer el esquema para todos los entregables a lo largo del ciclo de vida del
proyecto.
• Proveer un medio para integrar y evaluar el desempeño del costo y el trabajo.
• Facilitar la asignación de recursos.
• Facilitar el reporte y análisis del progreso e información del estado.
• Proveer un esquema para especificar objetivos de progreso.

2.3 IMPORTANCIA DEL WBS:

Teniendo en cuenta todas las aportaciones que el Work Breakdown Structure puede
llegar a brindar a un proyecto, éstas no aseguran una satisfactoria administración,

19
porque la experiencia dicta que siempre pueden surgir problemas y contratiempos en el
desarrollo, sin embargo los fallos suelen revelar que el proyecto carece de un buen WBS
o simplemente no cuenta con uno. Un WBS mal planificado, entre otras cosas, puede
generar adversidades como una definición incompleta del proyecto que conlleva a las
extensiones del proyecto en curso, trabajos y objetivos no especificados claramente,
incertidumbres en los alcances y con constantes cambios, superación del presupuesto
previsto, retrasos en los tiempos y en los plazos para entregables, productos que no
sirven, o fallos en la entrega de elementos del proyecto.

La importancia que tiene el WBS en un proyecto no radica únicamente en la

planificación y control sino que también se extiende por todos los grupos de procesos,
incluidos la inicialización y la ejecución. A continuación se muestra más a detalle la
implicación del WBS en cada uno de estas fases:

Inicialización:
• Desarrollo de la declaración preliminar del alcance del proyecto:
o Los elementos históricos del WBS pueden contribuir en la determinación
del alcance y viabilidad de los proyectos.

Planificación:
• Planificación del alcance:
o Este proceso documenta cómo será creado y definido el WBS.
• Definición del alcance:
o Posteriormente se define todo el alcance del proyecto.
• Definición de actividades:
o El WBS es una entrada de este proceso y un componente fundamental
para el plan del proyecto.
• Estimación de costos:
o El WBS es una entrada de este proceso.
• Preparación del presupuesto:
o El WBS es una entrada de este proceso e identifica los entregables del
proyecto a los cuales les serán asignados costos.
• Planificación de recursos humanos:
o El WBS es una entrada de este proceso y un componente clave para el
plan del proyecto.
• Identificación de riesgos:
o El WBS identifica los entregables de proyecto que deben ser evaluados
para casos de riesgo.
• Planificación de respuestas a los riesgos:
o El WBS deberá ser actualizado para incluir el trabajo y entregables
requeridos por la gestión de riesgos.
• Planificación de adquisiciones:
o El WBS es una entrada de este proceso.

Ejecución:
• Distribución de información:
o El WBS brinda la base para desarrollar el plan de comunicaciones y el
nivel de granularidad al cual la información del proyecto puede
distribuirse.

20
 o El WBS ayuda a determinar qué nivel de detalle del proyecto es
adecuado para comunicarse con los diferentes grupos de patrocinadores.

Monitoreo y Control:
• Verificación de alcances:
o El WBS facilita el proceso de aceptar formalmente los entregables
completos.
• Control de alcances:
o El WBS es una entrada de este proceso el cual es un componente
importante del plan de proyecto.
o Es importante ajustar el WBS si el alcance del proyecto es modificado,
de manera que los cambios futuros se basen en una línea base de
proyecto actualizada y aceptada.
o El WBS mejora la habilidad del administrador del proyecto de calcular
el impacto de cambios en el alcance.
• Control de costos:
o La creación del WBS revela el mejor punto en la jerarquía de entregables
en el cual implementar el control de costos.

2.3.1 Relaciones con otras herramientas:

El verdadero propósito del Work Breakdown Structure como una herramienta para la
administración es la de organizar, ordenar y dar una estructura al alcance de un
proyecto, y a su vez puede organizar el alcance de programas y portafolios haciendo uso
de técnicas similares. Entre las herramientas que son utilizadas por el WBS o sus
componentes como entrada figuran:
• Carta del proyecto: Es el punto de partida del WBS, el elemento más alto de la
jerarquía del WBS deberá representar al servicio o producto final global del
proyecto, tal como se describe en la carta del proyecto. Si los principales
productos no se pueden describir durante la creación del WBS, entonces el
equipo administrador del proyecto deberá examinar la carta para determinar si ha
sido suficientemente definidos.
• Declaración de alcance del proyecto: Este documento tiene como función
describir de manera breve y clara qué cosas trata y no trata de alcanzar el
proyecto. Los elementos de mayor nivel en la jerarquía del WBS deberán
coincidir literalmente con las descripciones de lo que figure en la declaración
respecto a lo que se quiere conseguir con el proyecto. Si el equipo administrador
del proyecto tiene dificultades para identificar los objetos en la declaración de
alcance y aplicarlos a los elementos de alto nivel del WBS, el equipo deberá
examinar cautelosamente la declaración de alcance para determinar si ésta
abarca suficientemente a todos los objetivos y entregables de proyecto. También
se puede hacer uso de un diccionario de WBS para documentar cada entregable.
• WBS del programa y portafolio: Se puede utilizar el WBS para definir alcances
para proyectos, programas y portafolios; por ejemplo, las oficinas de un
programa se establecen típicamente para compartir técnicas, herramientas,
metodologías y recursos para administrar una o más colecciones de programas y
proyectos relacionados. El WBS del proyecto debe ilustrar un claro
entendimiento de la relación entre paquetes de trabajo altamente subdivididos
dentro de definiciones de alcance de proyectos o programas (o inclusive de
orden mayor). Si se realizan cambios estratégicos, el impacto en proyectos,

21
 recursos y costos pueden calcularse fácilmente, asumiendo que le WBS del
proyecto se construyó correctamente con respecto a estos factores de orden
mayor.
• Resource Breakdown Structure (RBS): El RBS describe la organización de
recursos de un proyecto y se puede utilizar conjuntamente con el WBS para
definir las asignaciones de paquetes de trabajo. En enlace entre paquetes de
trabajo y el RBS puede usarse para verificar que a todos los miembros del
equipo del proyecto se les ha asignado apropiadamente paquetes de trabajo y que
todos los paquetes de trabajo tienen dueño.
• Organizational Breakdown Structure (OBS): Se puede decir que el OBS está
vagamente relacionado al WBS. El OBS subdivide la jerarquía de la
organización, permitiendo a los paquetes de trabajo ser relacionados a unidades
de desarrollo organizacionales. Esta herramienta refuerza la idea de que cada
paquete de trabajo debe tener un único grupo responsable. El OBS puede ser una
herramienta útil para los administradores del proyecto dado que demuestra
claramente la jerarquía de grupos o personas, mientras que el WBS es
organizado estrictamente por entregables.
• Diccionario de WBS: Este diccionario es un documento clave que acompaña al
WBS y lleva información crítica sobre el proyecto. El diccionario de WBS
define, detalla y clarifica los diversos elementos del WBS para asegurar que
cada componente del WBS es articulado precisamente y puede ser comunicado a
cualquiera que lo consulte. El desarrollo de este diccionario generalmente
presenta ambigüedad u otros errores en el WBS en sí, lo que conlleva a
modificaciones del WBS. Contiene información sobre cada elemento del WBS,
incluyendo una descripción detallada del trabajo, actividades o entregables
asociados con cada elemento. El diccionario de WBS debe también incluir una
indicación del tipo y número de recursos requeridos e información de control de
contrataciones; usualmente este diccionario incluye matrices de seguimiento,
enlazando el WBS a documentos de control de alcance, como por ejemplo las
declaraciones de trabajo o documentos de requerimientos.
• Diagrama de red del itinerario del proyecto: El diagrama de red es una
disposición secuencial del trabajo definido por el WBS, y es esencial para
revelar las dependencias y riesgos del proyecto. Las actividades dentro de los
paquetes de trabajo del WBS son acomodadas para mostrar orden y prioridad. El
desarrollo de un diagrama de red generalmente revela problemas en el WBS,
como una descomposición incompleta, la asignación de demasiado trabajo en un
elemento, o la asignación de más de una persona para un elemento individual de
WBS, y por ende necesitado de revisiones.
• Itinerario del proyecto: Los diferentes elementos del WBS son utilizados como
puntos de partida para definir las actividades incluidas en el itinerario del
proyecto. Las dependencias implicadas pueden ser incluidas en el diccionario de
WBS, y las actividades, tal y como se definen en el diccionario del WBS, son
incluidas en el itinerario.

Debido a las interrelaciones que existen entre el WBS y otras herramientas de

administración de proyectos, es importante el recordar que cualquier cambio que se
termine llevando a cabo en el WBS necesita de un cambio asociado en las herramientas
relacionadas.

22
En el WBS, el proceso de definición de actividades retrata a los objetivos a lograr como
una serie de actividades de itinerario en vez de como entregables, utilizando la técnica
de descomposición y formando parte del proceso de creación de WBS. La lista de
actividades, el WBS y el diccionario del WBS pueden ser desarrollados
secuencialmente o simultáneamente, pero con el WBS y el diccionario como la base
para el desarrollo de la lista de actividades definitiva. Los paquetes de trabajo se
descomponen en actividades de itinerario requeridas para lograr los entregables
respectivos a cada paquete de trabajo, y de esta tarea se encarga el personal del equipo
responsable del paquete de trabajo. La secuencia de las diferentes actividades requiere
la identificación y el documentado de las relaciones de precedencia lógicas sobre las
actividades de itinerario, en las cuales también se prevén adelantos y demoras para
apoyar el posterior desarrollo de un itinerario realista y alcanzable.

Existen varias herramientas de administración de proyectos que pueden ser utilizadas

para ayudar al administrador al desarrollo del WBS, muchas de las cuales suelen ser
estándares corporativos y facilitan el rápido comienzo del desarrollo del WBS; cuando
se hace uso de éstas, se debe procurar que concuerden bien con el tipo de proyecto y que
pronto se vayan adecuando para suplir las necesidades específicas del proyecto. Las
ventajas que presentan estas herramientas auxiliares del WBS son que brindan
consistencia y repetitividad al desarrollo del WBS, refuerzan los principios del estándar
del WBS, reducen significativamente el esfuerzo, simplifican los procesos y pueden
generar productos de WBS reutilizables.

2.3.2 Integración del WBS y uso por otros estándares:

Los estándares que toman ventaja del WBS se suelen clasificar en dos categorías: la
primera utiliza las salidas que genera el WBS como entradas, un ejemplo es el Practice
Standard for Earned Value Management (EVM) o el Practice Standard for Scheduling.
Los estándares de la segunda categoría incorporan al WBS como la herramienta
preferida para desarrollar la definición del alcance para su rol, como es el caso del
PMBOK o el OPM3, en el que ambos consideran al Pracice Standard for Work
Breakdown Structure.

2.3.3 Sumario:

El WBS es una importante herramienta para la planificación y ejecución de un proyecto

satisfactorio. Varios fallos de costos, itinerarios o de calidad del proyecto peden ser
tratados directamente como defectos en el desarrollo del WBS del proyecto. Es menos
probable que un proyecto tenga éxito sin la presencia de un WBS de calidad, pero en
contraparte, el desarrollar y aplicar un WBS de alta calidad en un proyecto aumentará
considerablemente la probabilidad de su satisfactoria finalización.

2.4 DEFINIENDO LA CALIDAD DEL WBS:

Cuando de habla de calidad en lo que a gestión de proyectos se refiere, se utiliza la

definición que se da de ésta en el libro del PMBOK, en donde la calidad es definida
como el grado al que un grupo de características satisface a determinadas necesidades;
en otras palabras, se puede decir que un WBS tiene alta calidad, si éste suple todas los

23
requerimientos para los que fue creado. Para medir la calidad del WBS existen dos
principios básicos que se amplían a continuación:

2.4.1 Primer principio de calidad del WBS:

“Un WBS de calidad es el que se construye de tal manera que satisface todos los
requerimientos para su uso en un proyecto.”

Existen dos sub-principios que satisfacen requerimientos de uso de un WBS, éstos

describen características de núcleo de cada WBS y características relacionadas al uso
que describe a un WBS en particular basado en su disposición individual y uso.

En lo que se refiere a las características núcleo, el WBS puede tenerlas como puede no,
y como tales representan los mínimos atributos específicos que el WBS debería
contener, por lo que la tenencia o no de dichas características mostrará la calidad que
tiene el WBS en cuestión. Entre estas características figuran:
• Es una agrupación de elementos de proyecto orientada a entregables
• Define el alcance del proyecto
• Aclara el trabajo y comunica el alcance del proyecto a todos los patrocinadores
• Contiene el 100% del trabajo definido en el alcance
• Captura los entregables provisionales, internos y externos en términos de trabajo
a completar, incluyendo la gestión del proyecto
• Se construye de tal manera que cada nivel de la subdivisión contiene el 100%
del trabajo del nivel anterior
• Contiene paquetes de trabajo que soportan claramente la identificación de tareas
que deben ser hechas para entregar el paquete de trabajo
• Otorga subdivisiones gráficas, textuales o de tablas del alcance del proyecto
• Contiene elementos que se definen con sustantivos y adjetivos, no verbalmente
• Organiza todos los entregables principales y secundarios en una estructura
jerárquica
• Utiliza un codificado para cada elemento que identifica claramente su naturaleza
jerárquica cuando es visto en cualquier formato como una tabla o un esquema
• Tiene al menos dos niveles con al menos un nivel de subdivisión
• Es concebido por la gente que realizará el trabajo
• Es construido con ayuda técnica de expertos entendidos en la materia y otros
patrocinadores, tales como directores de negocios y finanzas
• Evoluciona iterativamente junto con la elaboración progresiva del alcance del
proyecto, hasta el punto en que el alcance haya sido referenciado del todo
• Se actualiza en concordancia con el control de cambios del proyecto, de esa
manera permitiendo un mejoramiento continuo, después que el alcance del
proyecto haya sido completamente referenciado

Existe un conjunto de características relacionadas al uso, que varían de un WBS a otro y

lo hacen único, en función de las características del proyecto como el tipo de proyecto,
entorno, industria, etc. De manera similar a las características de núcleo, a éstas se les
mide la calidad en función de cuán bien son capaces de suplir las necesidades para las
que el WBS se emplea, desde el punto de vista de las características propias del
proyecto en cuestión. Las características relacionadas al uso permiten una adecuación
del WBS al contexto, entre los cuales se encuentran:

24
• Alcance de un nivel de subdivisión preciso: El grado de subdivisión al que se
puede llevar al WBS para tener una gestión óptima dependerá tanto de la entidad
como del proyecto que se este llevando a cabo. El nivel de detalle del WBS
estará en función de la complejidad del proyecto y cantidad de detalle necesitado
para su administración, pero siempre teniendo en cuenta que un paquete de
trabajo no debe ser muy pequeño para que no san excesivos los gastos de
control, ni muy grande como para que se vuelva un trabajo insostenible o que los
riesgos pasen desapercibidos.
• Capacidad de proveer suficientes detalles para comunicar todo el trabajo: El
WBS facilita la conceptualización y definición de los detalles relativos a un
producto, servicio o entregable, pero en nivel de detalle necesario para estos
diferentes elementos puede variar. Para asegurar una comunicación clara
refiriéndose al intento de cualquier elemento de WBS, la información específica
propuesta sobre el elemento de WBS deberá ser puesta en el diccionario del
WBS, minimizando así malentendidos del WBS y por ello, del alcance del
proyecto.
• Ser adecuado para el seguimiento como sea específicamente requerido: Pueden
haber entidades o proyectos que requieran de información muy detallada del
progreso al nivel de paquete de trabajo, como otras que simplemente necesiten
información sintetizada del proyecto a los niveles altos del WBS. En el WBS
hay ciertos puntos de síntesis desde los cuales se realiza el seguimiento del
desarrollo; éstos son definidos adecuadamente de manera que facilitan la
comunicación, el control del alcance, calidad, y la solidez técnica. En resumen,
el WBS brinda un mecanismo viable para poder evaluar el progreso.
• Ser adecuado para actividades de control: El WBS provee al administrador de
proyectos de un buen equilibrio entre las necesidades de control y un nivel
efectivo de detalle y complejidad del proyecto. Los proyectos pequeños o
simples no necesitan más que unas pocas inspecciones en los niveles altos del
WBS, mientras que los más complejos requieren varias revisiones en el WBS
del proyecto a los niveles más bajos; los elementos del WBS están lo
suficientemente detallados como para facilitar las actividades de medición,
monitoreo y control.
• Tipos de elementos de WBS específicos en función del proyecto: Los proyectos
pueden tener más o menos de los tipos de elementos de WBS a continuación,
dependiendo de sus necesidades:
o Algunos WBS pueden incluir elementos para integración, obtención,
gestión de la cadena de suministro, comunicación e información,
administración, documentación, preparación y desarrollo de software.
o Los elementos de WBS que representan entregables subcontratados
deberán corresponder directamente a los elementos del WBS de la
mencionada entidad externa.
o Un WBS deberá incluir elementos de WBS de ‘nivel de esfuerzo’.
o Entregables de las fases del ciclo de vida del desarrollo, como análisis,
planificación, diseño, ensamblaje, pruebas e implementación, pueden
reflejarse en el WBS, en donde sea adecuado.
o Los elementos de WBS pueden reflejar a los entregables dentro del ciclo
de vida del desarrollo de un producto, en donde sea apropiado, como por
ejemplo en la industria de tecnología de la información.
• Permitir la asignación de responsabilidades al nivel adecuado: De la misma
manera que el seguimiento del desarrollo de un proyecto en función de sus

25
 necesidades, los proyectos necesitan de la asignación de responsabilidades más o
menos detallada según sea el caso. Cada elemento del WBS se puede asignar a
una persona, equipo o subcontratado, e identifican las responsabilidades a un
nivel de detalle necesario para la administración de los mismos. El WBS es un
mecanismo que ayuda a la documentación de las responsabilidades al estar
vinculado al OBS a través de la RAM.
• Una estructura clara, concisa y bien organizada para alcanzar los requerimientos
de supervisión y gestión del proyecto: La lógica de la subdivisión jerárquica de
un WBS debe adaptarse a los factores del proyecto y de la entidad, de manera
que los elementos de WBS sean compatibles con las estructuras de
responsabilidad y de la organización, y el nivel de descomposición del proyecto
mantenga en equilibrio las ideas principales del proyecto con los requerimientos
de monitoreo de datos y reportes.

2.4.2 Segundo principio de calidad del WBS:

“Las características de calidad del WBS se aplican en todos los niveles de la definición
del alcance.”

No existen diferencias conceptuales entre el WBS de un proyecto, programa o

portafolio. Un WBS de alta calidad desarrollado a cualquiera de estos mayores niveles
posee exactamente las mismas características y atributos que un WBS de alta calidad
desarrollado en un nivel de proyecto individual; difieren únicamente en la amplitud del
contenido y alcance.

2.4.3 Sumario:

Existen diversas características que necesita el WBS para generar entregables de

calidad, pero en general, para que se considere de alta calidad, únicamente es requerido
que el WBS consiga satisfacer todas las necesidades para las que fue concebido. Un
WBS de alta calidad debe ser construido de manera consistente, ajustando su nivel de
enfoque al requerimiento; debe también disponer de todos los elementos que hagan falta
para representar la totalidad del alcance de trabajo, evitar errores comunes asociados a
su construcción, y ser manejable para administradores de proyecto con gran experiencia
en gestionar diversos tipos de trabajo, presupuestos, itinerarios y riesgos.

2.5 CONSIDERACIONES AL CREAR UN WBS:

Existen varias maneras para la creación de un Work Breakdown Structure, como por
ejemplo el ser desarrollado como un nuevo documento, puede reusar componentes de
otros WBS, pude basarse en plantillas o seguir estándares de WBS predeterminados. Si
se reutilizan componentes existentes, los elementos de WBS pueden ser extraídos de
proyectos similares o de platillas tipo estándar de otros proyectos que la organización
haya determinado convenientes. A continuación se expondrán guías para el proceso de
desarrollo del WBS y listas de inspección para el seguimiento y mejora:

2.5.1 Preparando al WBS:

26
El WBS puede ir variando iterativamente sus características en función de los objetivos
y propósitos del proyecto tanto técnica como empresarialmente, criterios de diseño de
desempeño y funcionales, el alcance del proyecto, requerimientos técnicos de
performance, entre otros. Un WBS de alto nivel (pocas subdivisiones) se suele
desarrollar en la fase conceptual del proyecto, pero una vez que se define el proyecto y
se preparan las especificaciones, se pasa a un WBS más detallado para tenerlo
personalizado a los requerimientos del proyecto. Para que el WBS represente el 100%
del trabajo no únicamente hay que subdividirlo con cuidado sino también descartar todo
tipo de trabajo y entregables innecesarios.

El WBS es considerado también como un medio más eficaz para brindar tanto al equipo
administrador como a los patrocinadores, una visión más amplia y con información más
precisa sobre el avance del proyecto, y como tal, existen una serie de preguntas que
ayudan a definir su desarrollo y ser iterativamente revisadas hasta que todas estén
debidamente respondidas y toda la información acarada; entre éstas destacan:
• ¿Están definidas y emitidas la declaración del alcance y la carta del proyecto?
• ¿Ya se asignó al personal que desarrollará el WBS?
• ¿Qué partes de componentes tiene el proyecto y cómo trabajan juntos?
• ¿Qué es lo que hay que hacer?
• ¿El proyecto ha sido planificado en su totalidad?
• ¿Ya se definieron los procesos a utilizar para conseguir los entregables?
• ¿Qué requerimientos de calidad son necesarios?
• ¿Requiere el proyecto de ayudas externas de algún tipo? ¿Cuales y de qué tipo?
• ¿Se hizo un análisis de riesgos e identificado el trabajo de gestión de riesgos?

Para crear un WBS existen una serie de herramientas de las que se puede hacer uso,
como resúmenes, tablas de la organización, diagramas, lluvia de ideas y estratégicas de
desarrollo hacia arriba y hacia abajo. No hay que olvidar que mientras sea posible, no se
debe ‘reinventar la rueda’, y reaprovechar información de WBS parecidos, de plantillas
o estándares para agilizar la labor. El uso de herramientas es siempre favorable debido a
que otorga consistencia y repetitividad, reforzando los estándares y modelos que se
establecieron por la empresa. Si se desea escoger el más adecuado de entre los
diferentes métodos existentes siempre se tiene que tener en cuenta primordialmente las
características y requerimientos del proyecto; a continuación se exponen las ventajas y
desventajas de algunos de los métodos más utilizados:

Método de
Ventajas Desafíos
creación de WBS
Top-Down • Estructura de manera adecuada • Requiere constante atención
(Bajada) al proyecto para reportes de que no se pasen por alto
estado paquetes de trabajo
• Ayuda a asegurar que el • El WBS necesita ser hecho a un
proyecto está lógicamente nivel detallado suficiente para
estructurado permitir el control de gestión
• Sirve cuando se determinan los
entregables
• Ubica a los entregables
adicionales mientras se van
encontrando

27
 Bottom-Up • Comienza con todos los • Identificar todos los
(Subida) entregables y trabajos hacia entregables antes de producir
atrás en un proyecto el WBS
• Confirma que todos los • Asegurarse que los paquetes de
paquetes de trabajo se incluyen trabajo se agrupen lógicamente
• Puede perder enfoque a groso
modo
Estándares de • Los formatos son predefinidos • Hacer que el proyecto encaje
WBS • Mejora la consistencia del WBS con el estándar
entre-proyectos • Puede inducir a inclusiones no
necesarias de entregables o
errores para incluir entregables
específicos
• No todos los proyectos encajan
en estándares de WBS muy
estructurados
Patrones de WBS • Da un punto de partida para la • Hacer que el proyecto encaje
creación de WBS con el estándar
• Ayuda a determinar un nivel de • Puede inducir a inclusiones no
detalle apropiado necesarias de entregables o
• Mejora la consistencia del WBS errores para incluir entregables
entre-proyectos específicos
• No todos los proyectos encajan
en estándares de WBS muy
estructurados
Tabla 1: Métodos de creación del WBS

Top-Down:
• Se deben identificar los productos u objetivos finales del proyecto, así como
revisar los documentos de alto nivel del proyecto, como la declaración de trabajo
o los requerimientos técnicos para dar consistencia entre el WBS y el proyecto.
• Definir los entregables más importantes del proyecto, que suelen ser entregables
intermedios necesarios para el proyecto pero que por sí solos no satisfacen las
necesidades del negocio.
• Subdividir los entregables más importantes a un nivel de detalle mayor y más
apropiado para la gestión del proyecto. Estos elementos de WBS de menor nivel
deben representar claramente un único entregable cada uno y cumplir la regla
del 100%.
• Actualizar el WBS hasta que los patrocinadores estén de acuerdo con la
planificación alcanzada, y que la ejecución y control finalmente sean capaces de
producir los resultados esperados.

Este método se suele utilizar más cuando en general el equipo que desarrollará el
proyecto tiene poco definido o claro el tema o otros aspectos relacionados, ya sea por
inexperiencia en el área, falta de claridad en los objetivos o en cómo realizarlos, o si se
dispone de una plantilla o información previa adecuada para la realización.

Bottom-Up:

28
 • Se deben identificar todos los entregables posibles en el proyecto únicamente,
todas las actividades relacionadas no se incluirán directamente pero sí se podrán
traducir como entregables asociados; con lo cual se abarcará la totalidad del
esfuerzo a realizar.
• Agrupar lógicamente los paquetes de trabajo.
• Agregar entregables al nivel superior o nivel padre, siempre cumpliendo la regla
del 100%.
• Una vez agregado un conjunto de tareas a un nivel superior, revisar de nuevo el
subconjunto para asegurarse que todo el trabajo haya sido abarcado.
• Repetir hasta que todos los elementos se hayan agregado a un último nivel que
represente al proyecto y asegurarse que la estructura final comprenda a todo el
alcance del proyecto.
• Actualizar el WBS hasta que los patrocinadores estén de acuerdo con la
planificación alcanzada, y que la ejecución y control finalmente sean capaces de
producir los resultados esperados.

El Bottom-Up es un método más adecuado para casos en que el equipo de trabajo

maneja mucha información o tiene mucho conocimiento del tema, como por ejemplo el
haber trabajado previamente con proyectos con objetivos muy similares, o conocer el
ciclo de desarrollo de los entregables del proyecto, o disponer de plantillas apropiadas
para el desarrollo:
• Estándares (Organizacionales) de WBS: Se define como un conjunto de
fundamentos con los cuales se construye un WBS, como lo son el formato,
esquema de numeración, consenso de nombres o elementos requeridos, dotando
de consistencia y haciendo más completos a los WBS en una organización.
• Patrones de WBS: Un patrón de WBS es como un formato o modelo de WBS
genérico y abstracto hasta cierto punto, al cual se le va agregando información
del proyecto y finalmente se termina adaptando a los requerimientos de éste. De
la misma manera que los estándares de WBS, los patrones otorgan una mayor
consistencia al WBS debido a la reutilización de componentes; en caso de no
necesitarse algún elemento del patrón, se descartará para que la totalidad del
trabajo distribuido se corresponda totalmente con los objetivos del proyecto.

Si se disponen de estándares de WBS, su uso es recomendado siempre y cuando se tome

en cuenta las advertencias mostradas en la anterior tabla, si se disponen de patrones de
WBS con aspectos similares a lo que se busca, su uso es recomendado; sin embargo, si
un proyecto difiere notoriamente de otros en la organización y no hay patrones
compatibles, se recomienda el uso del Top-Down.

Cabe hace mención que tanto para el método de patrones como para el de estándares, es
necesario repasar las preguntas de calidad de WBS formuladas al comienzo de este
apartado para asegurarse de haber construido un buen WBS.

No debe olvidarse que no es obligatorio utilizar únicamente un método, ya que se

pueden combinar varios de éstos; la finalidad es lograr que el WBS conseguido sea
orientado a los objetivos más que a las actividades, contemple el 100% del trabajo, y
tenga todas las características de un WBS de alta calidad.

2.5.2 Factores generales a ser considerados:

29
Los factores básicos a tener en cuenta para el WBS son los siguientes:
• Cada elemento de WBS representa un único entregable.
• Los entregables incluyen tanto a entregables finales como intermedios
requeridos para llegar a los resultados.
• Los entregables también incluyen partes intangibles, como la información,
comunicación, integración, administración, entrenamiento, gestión y logística.
• Todos los entregables son explícitamente incluidos en el WBS.
• Los entregables son únicos y distintos entre sí.
• Todos los mecanismos significativos de reportes como reuniones o informes,
deben ser identificados e incluidos en el WBS.
• Una clara definición de los objetivos, de manera que cada uno sea único, asegura
que no hayan duplicaciones en las salidas del proyecto o de proceso alguno.
• Las responsabilidades sobre cada paquete de trabajo se puede asignar a un único
equipo de desarrollo o entidad subcontratada. Si esto no es posible, entonces se
deberá reconsiderar si el paquete de trabajo deberá subdividirse o no.
• Cada elemento del WBS que represente a un entregable subcontratado
externamente, se corresponde directamente con elementos del WBS de la
entidad subcontratada.
• Los entregables se subdividen lógicamente a un nivel que represente cómo van a
ser producidos y gestionados.
• Todos los elementos de WBS son compatibles con las estructuras
organizacionales y de responsabilidades.

Las siguientes pautas se deberán tener en cuenta para organizar elementos de WBS en la
jerarquía del WBS:
• Cada elemento de WBS pertenece únicamente a un elemento ‘padre’ de WBS.
• El grupo de elementos ‘hijos’ en el cual un ‘padre’ es subdividido, incluye todo
el trabajo contenido en el ‘padre’.
• Se utiliza un esquema de codificación para elementos de WBS que representan
claramente la estructura jerárquica cuando se visualiza en formato de texto.
• Todas las ‘piernas’ de la estructura del WBS no necesitan ser del mismo nivel,
algunas áreas del WBS necesitarán de más detalles que otras, y por ende no
todos los paquetes de trabajo estarán al mismo nivel.
• El proceso de desarrollo del WBS debería ser iterativo, ser revisado como el
resto de procesos de planificación en desarrollo, y otorgar flexibilidad cuando el
alcance del proyecto cambie.

Un proyecto bien gestionado debe incorporar un proceso de control de cambios riguroso

para administrar y documentar los cambios en el alcance. Cuando se produzcan
cambios, se deberá actualizar tanto el WBS como sus herramientas asociadas.

De la misma manera en la que se dan consideraciones generales para el WBS, también

se debe tomar en cuenta las relaciones que existe entre el desarrollo del WBS y las
diferentes áreas de conocimiento del PMBOK, expuestas a continuación:

Administración de la integración del proyecto:

• Incluir el trabajo del WBS para la integración de componentes, poner a éstos al
mismo nivel de los componentes a integrar.

30
 • Incluir el trabajo del WBS para las comunicaciones como necesarios para el
desarrollo del proyecto.
• ¿Está el trabajo definido por el WBS agrupado lógicamente? ¿Los mecanismos
de control reportes ya fueron dirigidos?

Administración del alcance del proyecto:

• Revisar el WBS con frecuencia y estar preparado para hacer cambios en el
desarrollo del WBS, ya que es crítico para la administración del proyecto.
• ¿Han sido definidos y aprobados los requerimientos?
• Estar seguro de que cada elemento de WBS pueda ser contrastado con cada
requerimiento, incluir sólo las actividades que se consideren en el alcance y se
puedan contrastar con requerimientos contractuales o de otros tipos.
• Al definirse el WBS, realizar una lista de actividades que se consideren fuera del
alcance y confirmar el alcance con los patrocinadores con frecuencia, revisando
el WBS y la lista de actividades fuera.
• ¿Están todos los entregables explícitamente definidos en el WBS?
• ¿Se consultó data histórica, registros de riesgos, y otros factores aprendidos para
identificar todo el trabajo a realizar?

Administración del tiempo del proyecto:

• Los entregables se deberán subdividir a un nivel de detalle necesario para
estimar el esfuerzo requerido para obtenerlos.
• ¿Cómo se va a determinar el estado del trabajo en curso?

Administración de costos del proyecto:

• Los entregables se deberán limitar en tamaño y definición para un mejor control:
No muy pequeños como para hacer el costo del control excesivo, y no muy
grandes para que sea inmanejable o con muchos riesgos.
• ¿Cómo se distribuirá el presupuesto?
• ¿Se podrá relacionar el presupuesto a las designaciones de trabajo propuestas?
• ¿El nivel de detalle del WBS es justo para una buena planificación y control?

Administración de la calidad del proyecto:

• ¿Se evaluará la calidad del trabajo por esfuerzos como testeo o inspección?
• ¿Qué requerimientos de calidad hay? Revisar siempre los elementos de WBS
para ver que se estén llevando a cabo dichos requerimientos.
• ¿Los requerimientos piden conformidad con estándares como ISO, ANSI, etc.?
Si lo piden, incluir los elementos para revisiones externas.
• ¿Son los requerimientos definidos para los entregables propuestos en el WBS?
• ¿Se han definido métricas para los entregables a ser medidos?

Administración de recursos humanos del proyecto:

• Asegurar que cada elemento de WBS tenga una única responsabilidad, si el
elemento de WBS puede involucrar a personas de diferentes tipos de
responsabilidades, se considerará la subdivisión del elemento.
• ¿Se ha planeado el trabajo a un nivel de detalle necesario como para hacer y
mantener compromisos?
• Asegurar que la estructura de reportes indicada por el WBS soporta el establecer
y administrar asignaciones de trabajo individuales.

31
 • ¿Las asignaciones de trabajo pueden ser establecidas a partir de un WBS en
progresiva expansión?
• ¿Cómo se asignará y controlará generalmente el trabajo?
• ¿Será posible reconciliar asignaciones de trabajo individuales al sistema de
planificación de tareas formal?
• ¿Están involucrados más de una organización, necesitando la validación del
WBS con otros antes de realizar la planificación de recursos detallada?

Administración de las comunicaciones del proyecto:

• ¿Se tomaron en cuenta todas las necesidades de comunicación?
• ¿Se requieren comunicaciones de larga distancia, regional, nacional o
internacional?
• ¿Hal algún tipo de comunicación especial que se necesiten entre los entregables
propuestos en el WBS?

Administración de riesgos del proyecto:

• En donde sea considerado el WBS de alto riesgo, se debe considerar subdividir
el WBS a más detalle para permitir una mejor definición de suposiciones y
expectativas, incrementando la precisión y reduciendo el riesgo.
• ¿Son todos los entregables completamente y claramente definidos?
• ¿Cuál es la posibilidad de cambios?
• ¿Está la tecnología cambiando más rápido de lo que pueda tardar en proyecto?
• ¿Han sido revisados el personal, la capacidad de las instalaciones, disponibilidad
de recursos internos, y proveedores potenciales?
• ¿Se ha definido e implementado un proceso formal de cambios?
• ¿Se han definido métricas para cómo se medirán los entregables?
• ¿Se han identificado los requerimientos de recursos para el desarrollo de los
entregables?
• ¿Se han identificado otros tipos de riesgos?
• ¿Se han definido e implementado un plan de comunicaciones interno y externo?
• ¿Son comprendidos y supervisados para cambios las dependencias ajenas a la
empresa y asociados?
• ¿Se identificaron proveedores alternativos?
• ¿Se consultó información histórica, registros, listas de tareas y otros para
asegurar la identificación de riesgos?
• ¿Se incluyeron la gestión de riesgos y trabajos de contingencia?

Administración de las adquisiciones del proyecto:

• ¿Se esperan subcontrataciones extensas?
• ¿Hay un elemento de WBS para cada entregable adquirido?
• ¿Se necesitan entregables intangibles para gestionar los procesos de adquisición?
• ¿Las adquisiciones se gestionarán por el equipo del proyecto o por
organizaciones de adquisiciones?

2.5.3 Opiniones esenciales:

Los factores que pueden cambiar de un proyecto a otro, dependiendo de su propósito,

son entre otros el nivel de detalle adecuado de descomposición del WBS, la elección del
tipo de elemento de WBS a incluir, y la estructuración de la lógica de descomposición.

32
La aplicación efectiva de las características relacionadas al uso se basa en la opinión y
experiencia.

El nivel de detalle al que se descompone un WBS está en función al tamaño del

proyecto, de la complejidad que éste presente, y del nivel de control que desee ejercer el
equipo gestor. El proceso de desarrollo del WBS es iterativo, y le va incrementando el
nivel de detalle hasta que se llegue al punto de poder representar a todos los elementos
del alcance de trabajo. Este proceso brinda también un entendimiento necesario para
una comunicación clara y gestión efectiva del proyecto.

Un proyecto de corta duración puede tener un extenso grado de subdivisiones o detalle

desde el comienzo, mientras que para proyectos de larga duración lo normal es que se
empiece con un WBS de alto nivel y poco a poco se vaya entrando en detalle a medida
que se va avanzando con el proyecto. Esto quiere decir que en un WBS, algunas partes
pueden tener diferentes niveles de descomposición que otras, por lo que no hay
necesidad de descomponer todas las ramas del WBS si la necesidad sólo lo requiere en
algunas.

En caso de surgir dudas sobre si el WBS debe ser más detallado o no, existe una serie de
preguntas a continuación para ayudar a esclarecer si hay necesidad. De ser alguna
respuesta positiva, la subdivisión de deberá tener en cuenta, y cuanto más respuestas
afirmativas, más razones para ello.

Nivel de detalle del alcance y paquete de trabajo:

• ¿Faltan criterios claros y concisos para medir el progreso de elementos de WBS?
• ¿Algún elemento de WBS contiene más de un entregable?
• ¿Difieren los prerrequisitos entre entregables internos de un elemento de WBS?
• ¿Hay criterios de aceptación aplicables antes de acabar un elemento de WBS?
• ¿Los elementos de WBS son clara y completamente entendidos y aceptados por
el equipo de trabajo, patrocinadores, y el cliente?
• ¿Hay relaciones entre entregables internos de un elemento de WBS con otros
elementos externos de WBS?
• ¿Está el patrocinador interesado en analizar el desarrollo únicamente de una
parte del trabajo de un elemento de WBS?

Recursos y riesgos:
• ¿Se puede asignar un único grupo responsable a un elemento de WBS?
• ¿Hay riesgos específicos que requieran de atención especial a una parte del
elemento de WBS?
• ¿Se pueden identificar para cada elemento de WBS, riesgos de los que se puedan
tomar medidas?

Costos y cálculos de tiempo:

• ¿Hay tiempos muertos significativos en la ejecución de los procesos de trabajo
internos de un elemento de WBS?
• ¿Se necesita aumentar la precisión de las estimaciones de costo y duración de un
elemento de WBS?
• ¿Se necesita definir separadamente el costo de los diferentes procesos de trabajo
o entregables internos de un elemento de WBS?

33
 • ¿Se necesita de saber y reportar de manera precisa el cálculo del tiempo de
entregables internos de un elemento de WBS?

Un WBS organiza y define la totalidad del trabajo en un proyecto, sin embargo eso no
quiere decir que no todos los WBS necesitan incluir todos los tipos de trabajos posibles
en un proyecto; más bien, los tipos de trabajos incluidos deben regirse por el alcance y
el tipo de proyecto que se está llevando a cabo. No todos los proyectos, por ejemplo,
necesitan de un elemento de WBS de integración de resultados o partes.

Todo proyecto requiere de un WBS tanto para el trabajo a desarrollar como para la
gestión del mismo, y que este último tenga al menos elementos al segundo nivel de
jerarquía para asegurar una buena administración en términos generales. Si un proyecto
tiene ciertos requisitos de estándares de calidad, el WBS deberá incluir elementos en los
que se verifiquen los procedimientos especificados.

Existen varias maneras de orientar la lógica de subdivisión del WBS, las cuales siempre
dependen de los requerimientos de la empresa realizadora y del uso que se dará al WBS,
pero en cualquier caso es importante que el WBS se mantenga como orientado al
entregable más que orientado al procesos, y que contenga explícitamente todos los
entregables intermedios.

2.5.4 Evaluando la calidad del WBS:

Al crear un WBS hay varios puntos considerados esenciales, dentro de los cuales existe
un grupo de características núcleo imprescindibles, y la falla en algunas de éstas
conllevaría a que el proyecto fallase debido a un alto riesgo de que no se identifique
todo el trabajo requerido.

Características núcleo:
• La estructura del WBS no se basa en cálculos de tiempo o dependencias
secuenciales entre componentes, éstos últimos son asuntos del itinerado del
proyecto.
• El WBS no es estructurado estrictamente por procesos o la organización.
• El WBS define las relaciones lógicas entre todos los componentes del proyecto.
• Todos los elementos son orientados a entregables.
• Las actividades del proyecto no son listadas, así como los componentes del
itinerado del proyecto no lo son en el WBS.
• Todos los elementos son nombres y sustantivos, los verbos no se usan para
identificar elementos de WBS.
• El WBS incluye sólo entregables necesarios y suficientes, todos los entregables
son componentes necesarios del producto, servicio o resultado del proyecto, y
son definidos en el alcance del mismo.
• Todos los entregables, incluyendo permisos reguladores, presentaciones,
distribuciones o marketing, así como los entregables preliminares, intermedios,
internos, externos o finales, son identificados y detallados.
• No hay elementos de WBS con responsabilidades mixtas, cada elemento debe
tener una única persona o grupo claramente responsable por su finalización.

Otro punto esencial en la creación del WBS es el grupo de características relacionadas

al uso, las cuales permiten que el WBS se adapte al tipo del proyecto, industria o
34
 entorno en particular, y por lo tanto puede cambiar su apariencia. En este caso, la
calidad del WBS dependerá en qué tan bien el contenido específico y tipos de elementos
de WBS se adecuen al uso requerido.

Características relacionadas al uso:

• Identificación de trabajos de gestión del proyecto claves, tales como:
o Inicialización, planificación, ejecución, monitoreo y control, y cierre
o Administración de procesos
o Servicios y aprovisionamiento
o Información / comunicación
o Documentación administrativa, capacitación, y software
Éstos se deberán definir como elementos de WBS de nivel de esfuerzo o Level
of Effort, que pueden verse como entregables intermedios, los cuales no generan
por sí solos entregables discretos, y pueden no ser incluidos en la entrega del
producto final.
• Incluir elementos de WBS entre proyectos, tales como aquellos que representan
la abertura y cierre de etapas, por ejemplo, planificación, ensamblaje,
integración y testeo.
• Balancear los aspectos de definición del proyecto en el WBS con data recogida y
reportar los requerimientos. El propósito principal del WBS es definir el alcance
del proyecto a través de la descomposición de entregables.
• Subdividir el WBS al nivel de detalle apropiado para alcanzar un balance entre
complejidad y riesgo en el proyecto, y la necesidad del administrador del
proyecto de monitorear y controlar.
• No subdividir el WBS demasiado, cada WBS es una herramienta diseñada para
asistir al administrador del proyecto con la subdivisión sólo hasta los niveles
necesarios para suplir las necesidades del proyecto, el tipo de trabajo, y la
confianza del equipo. Demasiados niveles de WBS pueden requerir niveles
exagerados de mantenimiento y reportes.
• No omitir el desarrollo del WBS como la tabla de Gantt, el itinerario de CPM o
diagramas de precedencia antes del diagrama de red. Omitir el desarrollo y
refinamiento del WBS puede llevar a dificultades imprevistas, incluyendo
retrasos en el trabajo, excesos en el costo o un fuerte fallo en el proyecto.

2.5.5 Uso continuado del WBS:

El nivel en que el WBS pueda suplir las necesidades del proyecto es directamente
proporcional al nivel de competencia en gestión de proyectos que pueda tener el equipo
administrador. Un equipo administrador de proyectos con experiencia es capaz de
satisfacer una mayor cantidad de necesidades de un proyecto, así como ampliar variedad
de roles en los que se emplea el WBS, darle un uso más eficiente, y hacerlo de alta
calidad aún cuando no es usado en toda su capacidad. La buena utilización que el
equipo de administración haga del WBS en términos de definición y gestión del trabajo,
presupuesto y riesgo, sigue un continuado similar a la de cualquier otra herramienta de
administración de proyectos. A continuación se muestra un continuado de experiencia
para desarrollo y uso del WBS:

Limitado Intermedio Amplio

• Desarrollar un WBS que • Desarrollar un WBS que • Desarrollar un WBS que contenga
contenga todas las contenga todas las todas las características núcleo.

35
 características núcleo. características núcleo. • Identificar e incluir todos los
• Aplicar al menos un • Identificar e incluir atributos relativos al uso
mínimo nivel de algunos atributos relativos requeridos.
experiencia en al uso. • Aplicar el WBS efectivamente al
estimado de proyectos. • Aplicar el WBS desarrollo del itinerario de
• Aplicar conocimientos efectivamente al proyecto y asignación de recursos.
en la materia si es desarrollo del itinerario de • Aplicar técnicas de estimación de
apropiado. proyecto y asignación de proyectos en desarrollar y
recursos. gestionar el proyecto con WBS.
• Aplicar técnicas de • Aplicar el WBS efectivamente a la
estimación de proyectos planificación y ejecución, planif. y
en desarrollar el WBS. control de calidad, planif. y gestión
de riesgos, planif. y gestión de
costos, control de cambios, etc.
Tabla 2: Niveles de uso del WBS

2.5.6 WBS para administración de programas y portafolios:

Según el libro del Project Management Body Of Knowledge (PMBOK), un proyecto,

programa, y portafolio se definen de la siguiente manera:
• Proyecto: Un esfuerzo temporal llevado a cabo para crear un único producto,
servicio o resultado.
• Programa: Un grupo de proyectos relacionados, gestionados de manera
coordinada para poder obtener beneficios y control no disponible al gestionarlos
individualmente. Los programas pueden incluir elementos relativos al trabajo
fuera del alcance de los proyectos en el programa por separado.
• Portafolio: Un grupo de proyectos o programas y otros trabajos que son
agrupados para realizar una administración más efectiva de ese trabajo para
alcanzar estratégicos objetivos de negocios. Los proyectos o programas del
portafolio no necesariamente son interdependientes o están directamente
relacionados.

No existe una diferencia conceptual entre el WBS aplicable a proyectos, programas o

portafolios, pero el uso en estos dos últimos es una práctica en aumento. Un WBS de
alta calidad desarrollado para cualquiera de estos dos niveles mayores contiene los
mismos atributos y características de un WBS de alta calidad hecho sólo para un
proyecto, y por ende todos los principios definidos en el apartado anterior para un WBS
de proyecto son también aplicables para WBS de programas y portafolios. La única
diferencia del WBS en estos dos últimos radica en la amplitud del alcance, y por esto
mismo se tendrá que tener cuidado, dado que un aumento en el alcance representa un
aumento significativo en la verificación de cómo son definidos trabajos y entregables.

2.5.7 Sumario:

En conclusión al presente capítulo, se ha visto que un WBS se puede crear como un

documento completamente nuevo, o basado en platillas, reutilizando componentes de
otros WBS, o siguiendo estándares predeterminados. El WBS va cambiando
recursivamente en función al alcance y objetivos tanto de negocios como técnicos,
criterios de diseño funcionales y de desarrollo, requerimientos técnicos, entre otros. En
este capítulo se han presentado guías y listas de verificación para asistir la creación del

36
WBS. Todas las áreas de conocimiento de gestión de proyectos, sobre todo la de
tiempo, costos y calidad, son muy dependientes de WBS resultante. Finalmente, un
WBS de alta calidad sienta unas fuertes bases para el desarrollo exitoso de un proyecto.

37
CAPÍTULO 3: ESTÁNDAR PRÁCTICO PARA EL
ITINERADO

3.1 INTRODUCCIÓN:

Los proyectos son generalmente trabajos complejos, y es esencial un plan para guiar la
ejecución de un proyecto. A medida que se registra el progreso en un proyecto, el
trabajo restante requiere de una reevaluación en vista de la nueva información, es raro
que la ejecución de un proyecto proceda como se planificó inicialmente. El un típico
ambiente de proyecto, un proceso de itinerado definido y refinado es requerido para
predecir, reconocer, y dirigir aquellos factores y temas que puedan afectar
potencialmente el desempeño del proyecto. El propósito del itinerado es el de proveer
una ‘hoja de ruta’ o ‘roadmap’, que represente cómo y cuándo el proyecto entregará los
productos definidos en el alcance del proyecto y por el equipo del proyecto. La
naturaleza dinámica de la ejecución de un proyecto se sirve mejor por una herramienta
que permite modelar el plan y análisis debido al impacto del progreso y desarrollos
imprevistos.

La clave para el éxito del proyecto es aplicar conocimientos, experiencia, e intuición a

un plan de proyecto, y luego intentar ejecutarlos de acuerdo al plan. El itinerado es uno
de los requerimientos básicos para la planificación y análisis estratégico de la
administración de proyectos, su mayor objetivo es establecer el tiempo requerido por el
proyecto. Esto ayuda al proyecto a organizar fondos en las fechas requeridas, la
movilización de recursos de la manera más eficiente en costos y ahorrativa, a establecer
la coordinación dentro del proyecto y con otros proyectos, a la detección prematura de
problemas para que las acciones requeridas puedan implementarse de la manera
necesaria para alcanzar los objetivos estratégicos del proyecto como se planificó.
Además de un punto de vista contractual, el itinerario es un documento importante
utilizado para registrar todas las demoras y para analizar las extensiones de las
peticiones de pérdidas de tiempo y financieras. Otro objetivo es proveer una
herramienta para el análisis del ‘qué pasaría si’.

3.1.1 Visión general:

El uso apropiado de los componentes y sus prácticas resultarán en un itinerario útil para
planificación, ejecución, monitoreo, y comunicación de la entrega del alcance del
proyecto a los patrocinadores. El propósito del itinerado es el representar la entrega del
alcance del proyecto sobre el tiempo tal como lo define el equipo del proyecto. El
proceso de desarrollo del itinerario incluye la selección de un método de itinerado o
‘scheduling method’, y una herramienta de itinerado o ‘scheduling tool’, seguido por
incorporar los datos específicos del proyecto dentro de la herramienta de itinerado para
desarrollar un modelo de itinerario específico del proyecto. El modelo de itinerario del
proyecto se utiliza para generar itinerario(s) del proyecto. Este proceso resulta en un
modelo para la ejecución del proyecto el cual reacciona predeciblemente al progreso y
cambios. Una vez desarrollado, el modelo de itinerario es actualizado regularmente para
reflejar el progreso y los cambios, como el alcance o la lógica del itinerario.

Este estándar otorga una herramienta de evaluación que puede ser utilizada para
determinar qué tan bien los componentes de un modelo de itinerario dado se adaptan a
38
los requerimientos y recomendaciones documentadas en este texto. Se desarrolla un
índice de conformidad al determinarse qué componentes son utilizados y cómo son
utilizados dentro del modelo de itinerario. Para estar conforme con los requerimientos
estándar de itinerado aceptables, un modelo de itinerario debe, como mínimo, contener
todo el conjunto vital de componentes requeridos.

La inclusión de un componente en el estándar no necesariamente guarda ninguna

relación con las cuestiones de tamaño o complejidad del proyecto. En el presente
documento se asume que todos los modelos de itinerario tienen un conjunto vital de
componentes, comportamientos básicos, y buenas prácticas que pueden ser empleadas;
y por ello que el tamaño y complejidad del proyecto devienen únicamente en cambios
en la escala, repetición, y líneas temporales de los componentes vitales. El libro del
PMBOK pone a disposición procesos para dirigir los factores que refieren al tamaño y
complejidad del proyecto. Adicionalmente, lo ‘reconocido genéricamente’ también
asume diferencias no significativas entre los componentes vitales adecuados para
prácticas de itinerado, con diversas industrias. Las industrias pueden diferir en los
componentes que se incluyen aparte de los componentes vitales requeridos, con la
escala, repetición, y líneas temporales conduciendo el resto de la diferenciación. A
medida que las prácticas van evolucionando y desarrollándose dentro de la comunidad
de administración del proyecto después de la publicación de este texto, la definición de
lo ‘reconocido genéricamente’ también evolucionará. Se pueden añadir más
componentes al conjunto vital, y las buenas prácticas deben volverse menos subjetivas.

3.1.2 Propósito:

El principal propósito del estándar práctico para itinerado, es la producción de modelos

de itinerario que sean de valor creciente para los proyectos a los que representan.
Además, para dirigir adecuadamente las necesidades expresadas por la comunidad de
administración del proyecto, se considera esencial otorgar un medio para evaluar el
nivel de conformidad con este estándar práctico. Al hacerlo, se establece un conjunto
vital de componentes que deben ser utilizados para tener un modelo de itinerario que
cumpla con un nivel mínimo aceptable de conformidad.

3.2 EL PROCESO DE DESARROLLO DEL ITINERARIO:

El proceso de desarrollo del itinerario incluye seleccionar un método de itinerado,

herramienta de itinerado, incorporar datos específicos del proyecto dentro de la
herramienta de itinerado escogida para desarrollar un modelo de itinerario específico, y
generar el itinerario del proyecto. Este proceso resulta en un modelo para la ejecución
de proyectos que reacciona predeciblemente al progreso y a los cambios. Una vez
desarrollado, el modelo de itinerario es regularmente actualizado para reflejar el
progreso y cambios, en áreas como el alcance o la lógica.

Durante la planificación del proyecto, empieza un proceso para desarrollar un modelo

de itinerario que satisfaga las necesidades del proyecto y sus patrocinadores. Las
actividades deben ser descritas de manera única, incluyendo un verbo, al menos un
objeto, y cualquier actividad útil y esclarecedora. Los recursos requeridos para
completar cada actividad deben ser considerados para determinar la duración de cada
actividad. Las restricciones no deben ser utilizadas en el modelo de itinerario para

39
reemplazar a la lógica del itinerario. Cuando el modelo del itinerario está completo, se
debe establecer una línea base para poder realizar las comparaciones del progreso contra
el plan original. He aquí algunos puntos clave en el proceso de desarrollo del itinerario:
• Toda información relacionada con la gestión del tiempo del proyecto debe ser
revisada y servir como la base para definir cada actividad.
• Cada elemento del alcance del proyecto, como se define en el WBS, debe ser
soportado por una actividad, o actividades, que resulten en la finalización de esa
parte del alcance. Las actividades deben ser descritas de manera única,
incluyendo un verbo, al menos un objeto, y cualquier adjetivo esclarecedor útil.
• Una vez que la lista de actividades se defina, el orden en el cual las actividades
se realizarán deben ser determinados y registrados.
• Para evitar relaciones de actividades incorrectas o artificiales, el secuenciado
inicial de actividades debe de determinarse independientemente de la
disponibilidad de recursos. Después de completado el secuenciado de
actividades, las dependencias discrecionales, insertadas para dirigir las
disponibilidades de recursos, deben de utilizarse durante el proceso de desarrollo
de itinerario.
• Los recursos requeridos para completar cada actividad (incluyendo sus
disponibilidades y productividades) deben considerarse para determinar la
duración de cada actividad, si los recursos son realmente aplicados a las
actividades en el modelo de itinerario, o no.
• El desarrollo del modelo de itinerario debe utilizarse las salidas acumuladas de
los procesos de definición de actividades, secuenciado de actividades,
estimación de recursos para actividades, y estimación de la duración de
actividades.
• El modelo de itinerario incluye al menos dos hitos: el inicio del proyecto y el
final del proyecto.
• El modelo de itinerario debe desarrollarse enlazando cada actividad de acuerdo
con la secuencia de actividades y calculando las fechas tempraneras y tardías de
inicio y fin de las actividades. Esto se debe basar en la duración de actividades,
recursos, limitaciones externas, lógica de red, y la validación de suposiciones
utilizados en el desarrollo. Debe de ser posible rastrear todas las actividades en
el modelo de itinerario desde el hito inicial hasta el hito final y hacia atrás.
• Las limitaciones no deben utilizarse en el modelo de itinerario para reemplazar
la lógica de itinerario.
• Cuando el modelo de itinerario está completo, se debe establecer una línea base
para permitir comparaciones del progreso contra el plan original.
• Si el proyecto ya ha comenzado, el modelo de itinerario debe de actualizarse
regularmente con el progreso y cambios en áreas como el alcance y la lógica
para indicar el nivel al que cada actividad ha sido completada, en términos de
tiempo y recursos gastados y la cantidad de tiempo y recursos requeridos para
completar cada actividad.
• El progreso actual de de compararse a plan de línea base. Cualquier variación de
este plan de línea base, que exceda los límites de los valores umbrales
predeterminados de usuario, debe reportarse.
• Las acciones correctivas o cambios deben realizarse como parte del proceso de
control de cambios integrado, en donde el proceso de aprobación se documenta
para reflejar los cambios en el desempeño del actual proyecto.

40
3.2.1 El método de itinerado:

La introducción de datos específicos del proyecto, como de las actividades, duraciones,

y recursos, en la herramienta de itinerado crea un modelo de itinerario que es específico
para un proyecto en particular. Este modelo de itinerario, a su vez, es utilizado para
generar varios grupos de fechas, dependiendo en el intento de una iteración de
modelado específica. En consecuencia, el modelo de itinerario produce un itinerario de
proyecto, el cual contiene las fechas planificadas para completar las actividades.

El modelo de itinerario brinda una herramienta para analizar las alternativas. El equipo
del proyecto utiliza el modelo de itinerario para predecir las salidas y comparar cambios
en el modelo con las expectativas por parte del equipo de las consecuencias de la
variación como el progreso o alcance.

El modelo de itinerario puede utilizarse también para producir ‘critical paths’ o caminos
críticos e instancias de los itinerarios, así como otras salidas como los perfiles de
recursos, asignaciones de tareas, y registros de alcances logrados. Ello proveerá
predicciones basadas en el tiempo, reaccionando a las entradas y ajustes hechos a lo
largo de la duración del proyecto.

Proceso de análisis de riesgos del itinerario: Los modelos de itinerario proveen de

predicciones confiables de fechas y camino crítico únicamente si las relaciones de
actividades (predecesoras y sucesoras) son claramente definidas y las duraciones de las
actividades son conocidas con un alto nivel de certeza. El análisis de riesgos del
itinerario hace uso de información sobre la incertidumbre en las duraciones de las
actividades, construyendo pero también yendo más allá del modelo de itinerario bien
construido y del proceso de CPM, para ayudar a responder a las siguientes preguntas:
• ¿Cuál es la probabilidad de acabar el proyecto como se planificó?
• ¿Cuánta contingencia hace falta para establecer una fecha de finalización con
una probabilidad de éxito aceptable por los patrocinadores?
• ¿Qué actividades son las más propensas a retrasar el proyecto?
• ¿Qué acciones pueden tomarse para controlar los riesgos en el itinerario?
Si estimar duraciones de actividades involucra grandes incertidumbres, una técnica muy
utilizada es la aplicación de una estimación de tres puntos. Dichos tres puntos
corresponden a los valores de la duración optimista de la actividad, la duración más
probable, y la duración más pesimista. Para poder cuantificar la incertidumbre sobre la
duración general del proyecto, empezando de la estimación de tres puntos de cada
actividad, el PERT (que utiliza una aproximación de función de distribución Beta)
puede emplearse. Cuando la información sobre la duración de una única actividad se
representa por más de tres puntos (por ejemplo, por una PDF o función de probabilidad
general) o menos de tres puntos (por ejemplo, una función de distribución uniforme), o
aún cuando las suposiciones de PERT no se aplican (por ejemplo, el teorema del límite
central no es aplicable debido a muy pocas actividades en la secuencia), las
herramientas de simulación pueden emplearse (la simulación Monte Carlo).
El análisis de riesgos del itinerario debe utilizarse para proyectos en donde las
duraciones CPM estándares y los caminos críticos son vistos como riesgosos por los
patrocinadores. Además, el análisis de riesgos del itinerario deberá, como mínimo,
dirigir los eventos de riesgo identificados por tener alta probabilidad de impacto.

41
Cuando se emplee, el análisis de riesgos de itinerario debe basarse únicamente en los
modelos de itinerario que incluyan al menos los mínimos componentes requeridos por
este estándar práctico.
Las duraciones optimistas y pesimistas de las actividades representan los extremos de
las posibles duraciones. El estándar de estimación por tres puntos (por ejemplo,
optimista, más probable, y pesimista) de duración para análisis de riesgos debe hacerse
por aquellos que realicen las actividades o por alguien que tenga experiencia realizando
actividades similares. Si están disponibles resultados anteriores de actividades similares,
deberán ser referidos mientras se generan estas estimaciones de rango de riesgos.

3.2.2 El itinerario del proyecto:

Un itinerario de proyecto, en su forma más simple, es una tabla de actividades asociadas

con las fechas de itinerario cuando las actividades e hitos se lleven a cabo. En la
profesión de administración de proyectos, los itinerarios de proyecto son utilizados para
guiar la ejecución del proyecto así como para comunicar, tanto vertical como
horizontalmente, a todos los participantes y contribuidores al proyecto cuando ciertas
actividades y eventos se esperan que ocurran.

En la práctica de administración de proyectos actual, el término itinerario o ‘schedule’

es generalmente empleado indistintamente para referirse al modelo de itinerario
(típicamente una herramienta de itinerado de CPM computarizada con datos específicos
del proyecto ingresados y calculados) y las actividades con sus fechas asociadas. Para la
claridad y consistencia con el libro del PMBOK, este texto define los datos específicos
del proyecto dentro de la herramienta como modelo de itinerario y la lista resultante de
actividades con fechas, basado en los datos específicos del proyecto, como itinerario del
proyecto. Los itinerarios del proyecto pueden presentarse de varias maneras, incluyendo
listas simples, cuadros de barra con fechas, y diagramas lógicos de red con fechas, por
mencionar algunos ejemplos.

Los itinerarios del proyecto pueden tomar la forma de un itinerario de comienzo

reciente, de comienzo tardío, de línea base, de recursos limitados, u objetivo. Otros
tipos de itinerarios son en realidad derivados de estos cinco itinerarios básicos. Tales
derivados incluyen itinerarios maestros, de hitos, resumen de varios. El uso de estos
términos puede variar de proyecto a proyecto y de compañía en compañía.

3.2.3 Mantenimiento:

En intervalos regulares, a medida que el proyecto progresa, el modelo de itinerario debe

actualizarse. El mantenimiento de un buen itinerario es compuesto por dos procesos
principales.

Primero, el equipo del proyecto necesita reportar el progreso y desempeño en bases

periódicas y predeterminadas. Los criterios de reporte objetivos, así como la frecuencia
del reporte de datos, necesita establecerse cuando el itinerario es desarrollado. Por ello,
desde el inicio, todos los patrocinadores serán consientes y apoyarán los requerimientos
de reporte del progreso, como definidos en el plan de comunicaciones del proyecto. Una
vez que el desempeño y el progreso son reportados, el estatus actual del proyecto puede
ser comparado con periodos de reporte anteriores, incluyendo la línea base.

42
Segundo, El equipo del proyecto necesita desarrollar y mantener un proceso para los
cambios del modelo de itinerario. Dichos cambios pueden resultar en revisiones de
alcance o lógicas, pero a pesar de la fuente, el equipo deberá planificar su ocurrencia.

3.3 VISIÓN GENERAL DE LAS BUENAS PRÁCTICAS DEL MODELO DE

ITINERARIO:

La idea del modelo de itinerario es otorgar un mapa útil de rutas que pueda ser usado
por el administrador y equipo del proyecto para ayudarles a completar el proyecto con
éxito. El itinerario se vuelve una herramienta desarrollada por el equipo que refleja su
visión de cómo se hará el proyecto. El modelo de itinerario refleja cuándo se supone que
las actividades empiezan y terminan, y reacciona apropiadamente a los cambios en el
progreso, alcance, etc., a medida que se añaden al modelo de itinerario durante la vida
del proyecto. Un modelo de itinerario bien desarrollado es una herramienta dinámica
que puede usarse para predecir cuándo el trabajo que queda por completar puede
esperarse razonablemente que acabe. Simultáneamente, permite al equipo ver el
desempeño del proyecto a la fecha, y usar los datos para hacer proyecciones más
precisas sobre el futuro. Además, una vez finalizado el proyecto, el modelo de itinerario
del proyecto forma las bases para las actividades de lecciones aprendidas y una vez
actualizadas se vuelve el fundamento para proyectos similares en el futuro.

El modelo de itinerario describe el trabajo a ser realizado (qué), los recursos requeridos
para realizarlo (quién), y la secuencia óptima (comienzos de actividades, fines, y
relaciones) en la cual el trabajo se deberá realizar (cuándo). Establecer un modelo de
itinerario realista y alcanzable es una de las acciones iniciales en este proceso. Es de
igual importancia el reporte regular del estatus y la actualización del modelo de
itinerario para apoyar el monitoreo y control en curso del progreso a medida que se
ejecuta el trabajo del proyecto.

3.3.1 Diseño del modelo de itinerario:

El modelo de itinerario requiere de planificación y diseño de la misma manera en que

cada entregable del proyecto es planeado y diseñado. Para crear una herramienta útil
para controlar el progreso del proyecto y comunicar información referente al trabajo
planificado y progreso, el equipo necesita considerar un número de factores y buscar la
salida más óptima. Algunas de las cuestiones clave a considerar son:
• ¿Cuál es el nivel adecuado de detalle a utilizar en las actividades? Demasiado
detalle produce un modelo de itinerario muy largo y confuso que es difícil y caro
para gestionar; por otro lado, muy poco detalle significa que no hay suficiente
información para el control en curso del proyecto. Una simple línea guía
cualitativa que puede utilizarse para determinar el nivel de detalle es adecuada
cuando una persona asignada sabe exactamente qué requiere para realizarse sin
tener que depender de otras fuentes para ello.
• ¿Cuál es un ciclo apropiado para recoger el estatus del proyecto y actualizar el
modelo de itinerario? El periodo entre actualizaciones necesita ser lo
suficientemente largo para que la información de la última actualización haya
sido facilitada al equipo y para que el equipo pueda actuar con la nueva
información previamente a la siguiente actualización.

43
La elección de un tiempo de ciclo es influenciada por la ritmo de cambio en el proyecto;
para los proyectos relativamente estables y de bajo riesgo, un ciclo de estatus mensual o
bimensual puede ser adecuado. En cambio, para proyectos volátiles y de alto riesgo, las
actualizaciones pueden requerirse en cada cambio de sentido o inclusive a cada hora.
• ¿Qué ‘escala temporal’ debe utilizarse: minutos, horas, días, semanas, o meses?
La respuesta óptima depende de la frecuencia de los procesos de control y el
nivel de detalle necesario en las actividades. De todas maneras, las escalas
temporales deben mantenerse consistentes a través del itinerario del proyecto.
• ¿Qué requerimientos de reportes necesitará el itinerario para cumplir? La
comprensión el tipo de reportes requeridos por el modelo de itinerario para crear
una ‘instancia’ del itinerario del proyecto, provee orientación en las estructuras
de codificación óptimas que son necesarias para ser construidas en el modelo de
itinerario.

El desarrollo de un ‘buen itinerario’ se logra a través de la aplicación consistente de las

buenas prácticas en general. La experiencia adquirida con el tiempo ayudará al
itinerante a escoger las respuestas óptimas para las preguntas de diseño.

3.3.2 Elementos del desarrollo de un buen itinerario:

En este apartado se ofrece una visión general de los elementos esenciales que deben de
de ser considerados por el equipo del proyecto al desarrollar un buen itinerario. Las
buenas prácticas se muestran para cada componente en la lista de componentes de este
estándar práctico.

Desarrollo de la estructura del itinerado:

• Determinar cómo un modelo de itinerario será desarrollado: Al comienzo, el
administrador del proyecto, junto con el equipo, deben de determinar un plan de
desarrollo para el modelo de itinerario. Las consideraciones clave son:
determinar si se requerirá de la planificación de onda continua o ‘rolling wave’,
si el modelo de itinerario puede desarrollarse en su totalidad, y determinar los
patrocinadores de los cuales se requerirá su entrada como parte del proceso de
desarrollo del itinerario. Este texto se referirá a la persona que tome el mando en
el desarrollo del modelo de itinerario como el itinerante.
• Comprender el alcance total del proyecto: El itinerante necesita revisar y
entender los documentos de alcance del proyecto con particular énfasis en el
WBS. Dichos documentos brindan el trasfondo, información, y entendimiento
necesario para desarrollar el modelo de itinerario. El objetivo de este proceso es
de asegurar que todos los aspectos del alcance hayan sido adecuadamente
definidos e incluidos en el modelo de itinerario. Las actividades en el modelo de
itinerario representan el trabajo que produce los entregables o los paquetes de
trabajo identificados en el WBS; además, todos los elementos de trabajo en el
WBS deben ser directamente rastreables para una actividad de itinerario o grupo
de actividades. En cambio, cada actividad debe vincularse sólo a un elemento de
WBS.
• Identificar el proyecto e itinerario - ID de itinerario del proyecto: Cada modelo
de itinerario necesita de un nombre y número de identificación únicos para
identificar el proyecto. Cada versión del modelo de itinerario deben tener un
único número de versión o ID; es esencial para permitir el almacenaje adecuado
de los documentos de proyecto y procesos de revisión.

44
• Establecer calendarios de proyecto y periodos de trabajo: El itinerante
determinará, en acuerdo con el equipo, los periodos de trabajo que se
seleccionarán para el proyecto. Estos periodos de trabajo pueden ser diferentes
por actividades específicas o porciones del proyecto incluyendo los recursos.
Algunos de los temas de calendario a considerar incluyen:
o Número de días laborales en la semana
o Número de turnos a trabajarse cada día
o Número de horas a trabajarse cada turno o día
o Cualquier periodo del tiempo laboral o no laboral de ‘horas extra’
programado (feriados, por ejemplo)
Dichos elementos juegan un rol principal en determinar el número y estructura
de calendarios de proyecto requeridos para el itinerario. El uso de múltiples
calendarios introduce una complejidad significativa al cálculo de los fondos y
del camino crítico. De todas formas, mientras el itinerado se simplifica al usar
un único calendario, un calendario puede ser inadecuado para administrar el
proyecto. Una práctica generalmente aceptada es utilizar un calendario de
proyecto por defecto el cual sea adecuado razonable para realizar el trabajo,
basado en los tiempos de trabajo normales del proyecto. Este calendario del
proyecto puede ser luego utilizado como calendario primario o por defecto para
las actividades, esto permite al equipo establecer y programar diferentes
periodos de trabajo o calendarios, si son necesarios en ciertas actividades.
• Establecer el ciclo óptimo de actualización del proyecto: El equipo de
administración del proyecto, haciendo uso de la experiencia del itinerante,
deberá determinar la frecuencia apropiada para poder realizar actualizaciones y
medir estatus en el itinerario. Esto incluye determinar a qué punto en el ciclo
ocurrirá la actualización y con qué frecuencia se reportará el estatus. El ciclo de
actualizado debe considerar cómo la administración utiliza los datos generados
del modelo de itinerario, incluyendo el tiempo entre reuniones de revisión, los
requerimientos de reportes administrativos, y ciclos de pagos que generalmente
están ligados a las actualizaciones. La clave es seleccionar un tiempo de ciclo
que brinde a la administración un nivel óptimo de información de control sin ser
demasiado cargado de personal realizando el reporte y analizando, pero debe de
ser en general de un mes o menos. El ciclo de actualización óptimo variará con
la industria e intención del proyecto, que dependiendo de la aplicación del
mismo y varios otros factores, puede ser de cada hora a cada semana o mes. El
ciclo de actualización escogido tiene relación directa o correspondencia con las
duraciones de las actividades contenidas dentro del itinerario.
• Diseño de una estructura de codificación de actividad efectiva: Un estructura de
código útil y razonable debe de desarrollarse para poder seleccionar, ordenar, y
agrupar los datos de itinerario para facilitar el desarrollo y mantenimiento del
modelo de itinerario, así como suplir los requerimientos de reporte del proyecto
es fácilmente conseguido. Las estructuras de código bien diseñadas son también
muy útiles para analizar los datos de desempeño del proyecto al facilitar la
agregación, selección, y clasificación para enaltecer las tendencias y anomalías.
Un ID de actividad estructurada o sistema de numeración puede formar parte del
diseño de codificación general. Utilizar un sistema de numeración estructurado
puede permitir a los usuarios del itinerario comprender mejor cómo una
actividad en particular encaja en una imagen de proyecto mayor al entender el
significado del número de actividad en sí. Como mínimo, un número de
actividad debe de ser único, y seguir un sistema adecuado al proyecto. El énfasis

45
 debe ser colocado utilizando un sonido, una estructura de codificación de
actividades bien concebida que es diferente del identificador de actividad. Las
actividades pueden ser codificadas con más de un código para cada actividad,
cada código llevando su propio valor, además permitiendo salidas a ser
personalizadas para diferentes propósitos. Por ejemplo, los códigos pueden
emplearse para identificar fases, subfases, ubicaciones de trabajo, y organización
o persona responsable, en un proyecto. Los códigos pueden utilizarse solos o en
varias combinaciones. Para alcanzar la flexibilidad y funcionalidad mejoradas, la
mayoría de software de itinerado soporta códigos múltiples para cada actividad.
• Determinar los requerimientos de planificación de recursos: Si el itinerario es
tomar en cuenta la disponibilidad de los recursos, el grupo de recursos
disponibles al proyecto necesita ser determinado junto con cualquier calendario
de recursos especial, conjuntos de habilidades, y disponibilidades. Los recursos
usados con propósitos de itinerado pueden ser los mismos o un subconjunto de
los recursos utilizados para estimar los costos. Apenas se puedan utilizar los
códigos de las actividades para clasificar y organizar actividades, los códigos de
recursos pueden asignarse a los recursos para clasificarlos de acuerdo a la
organización, nivel de habilidad o tipo, estructura de reporte, etc. Además,
apenas como los IDs de actividad deben de ser estructurados en un sistema
significativo, los IDs de recursos deben de ser estructurados similarmente.

Desarrollo del itinerario base:

• Definir hitos: Una vez que el itinerante tenga una sensación respecto a la
estructura global de datos del proyecto discutidos previamente, podrá comenzar
a preparar los hitos del proyecto. Los hitos no tendrán duración, serán utilizados
como puntos de referencia para comparar el progreso, y pueden también reflejar
los puntos iniciales y finales para los diversos eventos o condiciones del
proyecto. Generalmente, un hito representará el comienzo o final de una parte
del proyecto y/o puede estar asociado con limitaciones externas, como la
finalización de un entregable o la recepción de entradas externas. Como mínimo
cada proyecto tienen que tener hitos de inicio y fin.
• Diseño de las actividades del proyecto: El itinerante, junto con los responsables
de realizar el trabajo del proyecto, pueden comenzar a crear la lista de
actividades que requerirán hechas para completar el proyecto. Las características
de una actividad bien diseñada incluye:
o La actividad es un elemento (o bloque) discreto de trabajo que es un
elemento tangible del alcance del proyecto.
o Una única persona debe de ser responsable de realizar la actividad. Esto
no impide la idea de que múltiples recursos puedan ser requeridos para
completar la actividad, pero si requiere que una entidad única sea la
responsable por su desempeño. Aquella persona debe de ser la misma
que reporte el progreso en la actividad.
o Las actividades describen el trabajo que debe de completarse, Como la
descripción para cada actividad debe comenzar con un verbo o contener
un objeto único. Los adjetivos pueden ser útiles para esclarecer
ambigüedades, pero cada descripción debe ser única y no dejar lugar a
confusiones.
o El trabajo representado por una actividad debe, una vez empezado, ser
capaz de proceder a la finalización sin interrupción (excepto por las
ocurrencias normales de periodos no laborables en el calendario). Si el

46
 trabajo en una actividad se suspende o demora, es normalmente
beneficioso para la actividad ser dividida en dos o más actividades en
puntos de ruptura naturales.
o El trabajo contenido en una actividad debe de ser tomado en cuenta para
que la duración de la misma sea menos que dos veces el ciclo de
actualización (idealmente nunca más que tres veces el ciclo de
actualización). Esto permite el reporte de comienzo a fin de una actividad
dentro de uno o dos ciclos de actualización, permitiendo a la
administración centrarse en el desempeño y acciones correctivas si es
necesario. Las excepciones a esta regla general son las actividades
continuas, actividades de obtención en donde un solo elemento de trabajo
puede tomar significativamente más que los tres ciclos de actualización,
o una actividad de nivel de esfuerzo como soporte administrativo. En
dichos casos, la duración de la actividad debe reflejar el tiempo
anticipado para la actividad. Se debe dar atención a las tareas de nivel de
esfuerzo, debido a que son iguales en duración a todo el proyecto, y
pueden acabar o manejar el camino crítico, el cual eclipsará las
actividades de lujo de trabajo más importantes.

Una vez finalizado, la lista de actividades debe describir al 100% el trabajo requerido
para completar el proyecto, a pesar que no todas las actividades necesariamente
requieran ser detalladas del todo si se utiliza la planificación de onda continua. Dicha
planificación implica planificar el trabajo de término cercano a detalle y presentar el
trabajo futuro a un nivel de sumario hasta el tiempo en que ese trabajo se acerque.
• Diseño de la lógica del proyecto: Conectar las actividades e hitos junto con
lógica ‘sensible’ es el fundamento de cualquier modelo de itinerario. El método
de conexión se define como una relación. Cada actividad e hito excepto el
primero y último debe de ser conectado al menos a un predecesor y a un sucesor.
Con la excepción del hito inicial, algo debe ocurrir previo al inicio de una
actividad, y a cambio, esa actividad debe de ser total o parcialmente completada
para permitir iniciar otra actividad. Asegurar la complicidad con esta práctica
prevendrá al itinerario de contener finales abiertos, en donde las actividades o
hitos no tienen predecesores o sucesores. La mayoría de las veces, cada
actividad deberá acabar antes de empezar su actividad sucesora (o actividades)
(conocida como una relación ‘finish-to-start’ (FS)), pero que no siempre es
posible. Si es necesario solapar actividades, el itinerante puede elegir utilizar las
relaciones ‘start-to-start’ (SS), ‘finish-to-finish’ (FF) o ‘start-to-finish’ (SF).
Siempre que sea posible, la relación lógica FS debe de usarse. Si es necesario
utilizar cualquiera de los otros tipos de relaciones, el itinerante debe usar pocas
veces y comprender completamente cómo las relaciones fueron implementadas
en el software de itinerado en uso. Idealmente, la secuencia de todas las
actividades serán definidos de tal manera que el inicio de cada actividad tenga
una relación lógica a un predecesor y el final de cada actividad tenga relación
lógica a un sucesor. El itinerante debe también asignar lapsos a algunas
relaciones. Un lapso impone un retraso entre la actividad precedente y la
sucesiva. El itinerante está advertido de utilizar los lapsos con cuidado y
comprender su impacto, como regla general, los lapsos negativos deben ser
usados únicamente cuando la lógica alternativa no es práctica. Algunos
itinerantes pueden estar tentados de utilizar los lapsos para representar un
periodo de tiempo en el que el trabajo está ocurriendo, como la revisión de un

47
 documento antes que proceda la siguiente fase. Se recomienda que este tipo de
trabajo sea mostrado como actividades en el modelo de itinerario en vez de
usarlo como lapso. Cuando tales actividades se incluyen, pueden ser codificadas
para mostrar que éstas son actividades para las cuales otra parte es responsable,
por ejemplo, el cliente. Esta práctica permite un mejor control del proyecto y
hacer más fácil el cambiar la duración de la revisión, si es necesario, comparado
a los tiempos de lapso cambiantes. Los itinerantes deben ser concientes que
cuando un modelo de itinerario de proyecto utiliza más de un calendario, puede
afectar los resultados de lapsos calculados, Adicionalmente, es de vital
importancia entender qué paquetes de software diferentes utilizan calendarios
múltiples. También es posible asignar limitaciones a las actividades e hitos que
requieran que la actividad o el hito empiecen o terminen en puntos específicos
del tiempo. Se recomienda especialmente al itinerante estudiar los diversos tipos
de restricciones que pueden utilizarse y comprender el efecto y matiz que su uso
tienen sobre el itinerario. La práctica generalmente aceptada es que las
limitaciones y lapsos no se empleen para reemplazar a la lógica.
• Determinar la duración de cada actividad: La duración es una estimación de
cuánto tomará el cumplir con un trabajo envuelto en la actividad (cantidad), en
varios casos, el número de recursos que se espera tener disponibles para
completar la actividad puede determinar su duración. Un aumento o reducción
de un recurso de conducción asignado a una actividad tendrá un efecto diferente
en la duración (pero no quiere decir que sea una simple relación ‘lineal’). Otros
factores que influencian la duración son el tipo o nivel de habilidad de los
recursos disponibles para realizar el trabajo, los calendarios de recursos, y la
naturaleza intrínseca del trabajo. Algunas actividades tomarán un tiempo para
completarse a pesar de la asignación de recursos. Mientras sea factible
determinar la duración de una actividad en cualquier momento, las prácticas
generalmente aceptadas recomiendan definir primero la actividad, luego atarla
lógicamente en la secuencia de itinerario general, y luego centrarse en cuánto
tardará en completarse. A estas alturas, la relación entre la actividad y otros
trabajos en el itinerario serán apreciadas más fácilmente; y los flujos de recursos,
tamaños de equipos de una actividad, y similar pueden comenzar a determinarse.
• Analizar la salida del itinerario: Una vez completado, el modelo de itinerario
será comprendido por un número de actividades únicas de duraciones variables,
con relaciones lógicas definidas. Ello brinda al equipo la información necesaria
de lo que se debe de lograr la secuencia requerida para conseguir los entregables.
Sin embargo, aún no indica cuándo realizarlo; para poder adquirir esa
información, la herramienta de itinerado es activada para calcular las fechas y
otros valores dentro del modelo de itinerario de acuerdo a los métodos de
itinerado escogidos. A pesar de la velocidad de varios programas informáticos,
la función de itinerado requerirá siempre de tres procesos distintos para un
‘análisis temporal’ y de un cuarto en caso se aplique un nivelado o suavizado de
recursos. Los pasos discretos son:
o Una fecha de inicio es asignada para el hito inicial, luego es movida a
través de la red de actividad en actividad (de izquierda a derecha) y en la
secuencia definida por las relaciones lógicas, las fechas de inicio y fin
son asignadas a cada actividad e hito, como determinado por las
duraciones definidas. A ello se le denomina el paso adelante o ‘forward
pass’. Las fechas de inicio y fin en cada actividad son denominadas

48
 fechas iniciales y cuando el análisis llega al fin de la red, establece la
primera fecha final posible para el proyecto.
o Paso seguido, se asigna una fecha final hito final, la cual puede ser la
misma fecha que la calculada por el paso adelante, o se aplica una fecha
diferente como limitación. El proceso de análisis luego trabaja a la
inversa a través de la red de derecha a izquierda hasta llegar al hito
inicial, y otro grupo de fechas de inicio y fin es asignado a cada
actividad. A esto se le denomina el paso hacia atrás o ‘backward pass’, y
establece las fechas tardías para cada actividad e hito.
o Los valores oscilantes se calculan al comparar las fechas iniciales y
finales de la siguiente manera:
ƒ El oscilante total es calculado al restar la fecha de fin inicial de la
fecha de fin final (se aplica también a las fechas de inicio).
ƒ El oscilante libre es calculado al restar la fecha de fin inicial de la
actividad, de la fecha de inicio inicial del más cercano de sus
sucesores. El oscilante libre nunca será negativo.
o Una vez calculados los valores oscilantes, el nivelado o suavizado de los
recursos debe llevarse a cabo para minimizar las sobre-asignaciones
recursos o reducir las fluctuaciones en la petición de recursos. Si este
proceso se debe realizar automáticamente, el itinerante debe determinar
los procesos y algoritmos a ser utilizados. La mayoría de paquetes
software de administración de proyectos tienen múltiples opciones y
ajustes que pueden tener un impacto significativo en el itinerario de
recursos nivelados resultante. Algunos itinerantes pueden estar tentados
de realizar nivelado de recursos manualmente ajustando la lógica o
añadiendo restricciones para retrasar el inicio de ciertas actividades. Ello
no es una buena práctica ya que interfiere con el cálculo normal de
itinerado.
• Aprobar el itinerario: El equipo del proyecto debe ser involucrado de manera
activa en revisar los resultados de este proceso de itinerado inicial. La revisión
deberá considerar la fecha de fin del proyecto analizado, las fechas de los hitos
de finalización, y los requerimientos de recursos (comparados a la disponibilidad
de recursos) para determinar la aceptación del itinerario. En donde son
requeridas las alteraciones, las variaciones se realizan a la lógica del itinerario,
asignación y/o duración de los recursos, y luego el itinerario es vuelto a analizar.
La alteración más frecuentemente buscada requiere acciones para reducir la
duración global del itinerario. Las técnicas clave utilizadas para acortar el
itinerario son la de estrellado o ‘crashing’, y la de rastreo rápido o ‘fast
tracking’. Dichas iteraciones continuarán hasta que se desarrolle un itinerario de
proyecto aceptable, uno con el que todos los patrocinadores del proyecto puedan
estar de acuerdo.
• Referenciado del itinerario: Una vez acordado, la primera versión del itinerario
que está completa para ser aprobada para capturar o ser copiada para referencias
futuras se denomina itinerario base del proyecto. Esta línea base se vuelve un
punto de referencia contra el cual el desempeño del proyecto puede ser medido.
Es una práctica generalmente aceptada que cada proyecto deba tener un
itinerario base listo antes que la ejecución del trabajo del proyecto comience.
Una vez aprobada dicha base, los reportes son distribuidos de acuerdo al plan de
comunicación del proyecto y los cambios son monitorizados y controlados a
través del proceso de control de cambios integrado.

49
• Mantenimiento del itinerario: El cambio es algo inevitable y cada proyecto lo
experimenta. El último gran componente requerido para asegurar una ejecución
exitosa del proyecto es un control de cambios efectivo. La clave está en
determinar cómo el proyecto aprobará y seguirá los cambios cuando ocurran a
través del ciclo de vida del proyecto. Los cambios pueden ocurrir simplemente
por el trabajo progresando de forma más rápida o lenta de la planeada, así como
cuando los cambios en otros elementos de trabajo del proyecto ocurren (cambios
de alcance, por ejemplo) y/o si el equipo decide modificar su enfoque. El
proceso de estatus o actualización ocurre con regularidad determinado durante el
proceso de planificación del proyecto. Los pasos involucrados para mantener el
itinerario en cada estatus/actualización son:
o Recoger y registrar el estatus actual del trabajo a una fecha/tiempo
predeterminado por el proyecto. La información recogida debe incluir las
fechas de inicio actuales para todas las actividades que han empezado, y las
fechas de fin actual para todas las actividades finalizadas durante el ciclo del
reporte. En donde una actividad está en progreso, la cantidad de trabajo
realizado y el tiempo necesario para completar el trabajo restante debe de
determinarse. Otra información recogida en este momento puede incluir
datos de utilización de recursos y costos incurridos. Los datos son recogidos
en una fecha o tiempo determinados. Dicha fecha o tiempo se le denomina
fecha de datos o ‘data date’, y es análogo al ‘time now’ en el EVPM (Earned
Value Performance Management).
o Se debe de ingresar información de estatus en el modelo de itinerario y
volver a analizar el trabajo que resta para determinar el estatus del proyecto.
Todo trabajo incompleto será reprogramado a una fecha o tiempo posterior
al del ‘data date’. Se debe vigilar, ya que varias herramientas software
permiten que se apliquen fechas actuales al trabajo futuro, y las prácticas de
control de calidad deben estar en su sitio para evitar esta situación.
o Comparar las salidas recientemente actualizadas del modelo de itinerario con
la línea base almacenada y, cuando sea necesario, emplear acciones para
atrapar las ganancias y/o recuperar las pérdidas (Gestionar las varianzas de
itinerario). Debido a las normales varianzas pequeñas en la ejecución del
proyecto respecto al plan, los umbrales de varianza pueden ser usados para
determinar qué actividades y condiciones requieren reportes y/o mayor
acción. Una varianza de datos muy comúnmente utilizada es la varianza de
finalización entre el fin inicial y la línea de base del fin, la cual se suele
expresar en unidades como días de trabajo.
o Actualizar el itinerario con cualquier cambio acordado resultado de un
proceso de control de cambio global para asegurar que el modelo de
itinerario representa el 100% del alcance de trabajo actual del proyecto. Los
procesos de ajuste y actualizado pueden requerir de un número de iteraciones
para mantener el modelo de itinerario que siga siendo realista y alcanzable.
o Distribuir los reportes de acuerdo al plan de comunicación del proyecto una
vez que se haya confirmado que el itinerario actualizado es preciso.
o Actualizar la línea base si los cambios de alcance autorizados han sido
incorporados en el modelo de itinerario actualizado.
o Mantener registros que expliquen todos los cambios de duraciones o lógica
de las actividades a medida que las alteraciones son hechas en el itinerario.
Las notas de registro de actividades son generalmente empleadas para este

50
 propósito. Dichos registros brindarán datos importantes si es necesario
reconstruir lo que ha ocurrido y porqué.

Todas las buenas prácticas y elementos descritos previamente son también incluidos
dentro de los detalles de cada componente contenido dentro de la lista de componentes
del modelo de itinerario como se ha expuesto previamente. El itinerante debe asegurar
una comprensión total y a fondo de los diversos componentes para poder maximizar el
potencial para su próxima aplicación y el desarrollo de un itinerario firme.

3.4 COMPONENTES DEL ITINERADO:

En esta sección se brinda una catalogación detallada de los potenciales componentes de

una herramienta de itinerado. Cada entrada incluye cinco tipos posibles de información
relacionada con cada componente, e indica si el componente se considera requerido u
opcional por este estándar. Los componentes requeridos deben de estar presente en un
modelo de itinerario antes que se pueda realizar una evaluación de madurez.

3.4.1 Cómo utilizar la lista de componentes:

Debajo se expone un ejemplo del formato para cada componente dentro de la lista de
componentes:

Nombre del componente Uso requerido u opcional Manual o calculado

Formato de los datos:
Comportamiento:
Buenas prácticas:
Nota condicional/Componente asociado:
Definición:
Tabla 3: Formato para componentes

• Nombre del componente: Este elemento de datos contiene el nombre del

componente dentro de la herramienta de itinerado.
• Uso requerido u opcional: Este elemento de datos indica si el uso de un
componente se requiere para conformar mínimamente el modelo de itinerario.
• Manual o calculado: Este elemento de datos indica si los datos dentro del
componente son ingresados manualmente o calculados por la herramienta de
itinerado.
• Formato de los datos: Este elemento de datos describe cómo los datos son
formateados dentro del componente como parte de la herramienta de itinerario.
• Comportamiento: En la lista de componentes, este elemento de datos describe
cómo el componente reacciona y/o permite reacción dentro de la herramienta de
itinerado. Cabe resaltar que todas las descripciones de comportamiento
empiezan con un verbo indicando una acción.
• Buenas prácticas: En esta lista, ‘buenas prácticas’ significa que hay un acuerdo
general en que la correcta aplicación de habilidades, herramientas, y técnicas
pueden mejorar las posibilidades de éxito sobre un amplio rango de proyectos
diferentes. La buena práctica no significa que el conocimiento descrito sea
siempre aplicado uniformemente en todos los proyectos; el equipo de

51
 administración del proyecto es responsable de determinar qué es lo apropiado
para cualquier proyecto dado.
• Nota condicional/Componente asociado: Este elemento de datos indica si la
acción del componente depende del estado o acción de otro componente.
• Definición: Este elemento de datos describe el uso general y función del
componente dentro de la herramienta de itinerado. La definición otorgada en
este punto es del glosario.

A continuación se expone un ejemplo de componentes en una lista categorizada:

Calendario

Calendario de actividad Opcional Manual

Formato de los datos: Fecha/Tiempo
Comportamiento: El calendario de actividad puede anular el calendario del proyecto para las
actividades a las que se aplica.
Buenas prácticas:
Nota condicional/Componente asociado:
Definición: Usualmente el calendario del proyecto, u otro calendario definido
específicamente de la librería de calendarios, asignada a la actividad de itinerario que define
los periodos de trabajo y no-trabajo en formato del calendario. El calendario de actividad, en
las actividades del itinerario a las cuales se asigna, se utiliza para reemplazar al calendario del
proyecto durante el análisis de redes de itinerario.
Tabla 4: Ejemplo de componentes #1

Calendario del proyecto Requerido Manual

Formato de los datos: Fecha
Comportamiento: Define los periodos de trabajo por defecto para el proyecto.
Buenas prácticas: A nivel de proyecto, esto debe constituir el calendario primario o por
defecto para el proyecto.
Nota condicional/Componente asociado:
Definición: Un calendario de días de trabajo o cambios que establecen aquellas fechas en las
cuales las actividades de itinerario son trabajadas, y días de no-trabajo que determinan
aquellas fechas en las cuales las actividades de itinerario están son avanzar. Típicamente
define feriados, fines de semana, y horas de descanso. El calendario inicialmente asignado a
las actividades de itinerario y recursos. Mirar también el Calendario de recursos y Calendario
de actividades.
Tabla 5: Ejemplo de componentes #2

Calendario de recursos Opcional Manual

Formato de los datos: Fecha/Tiempo
Comportamiento: Define el tiempo que un recurso está disponible para el trabajo.
Buenas prácticas:
Nota condicional/Componente asociado: ID de recurso
Definición: Un calendario de días de trabajo y no-trabajo que determina aquellas fechas en
las cuales cada recurso específico está sin utilización o activo. Típicamente define feriados
específicos de recursos y periodos de disponibilidad de recursos. Mirar también Calendario
del proyecto y Calendario de Actividades.
Tabla 6: Ejemplo de componentes #3

52
3.5 ÍNDICE DE CONFORMIDAD:

El índice de conformidad identifica el nivel de conformidad de un modelo de itinerario

respecto a este texto. La lista de componentes identifica aquellos componentes que
deben ser utilizados para tener un modelo de itinerario mínimamente aceptable. Como
condiciones, circunstancias y garantía de experiencia, se deben aplicar componentes
adicionales, opcionales, y más avanzados. Por tanto, en índice de conformidad de un
modelo de itinerario deberá incrementarse según se utilicen más componentes
avanzados.

El concepto de conformidad de modelo de itinerario permite a un asesor, desarrollador,

u otra entidad, determinar objetivamente qué tan bien el modelo de itinerario utiliza los
componentes y conceptos básicos de itinerado de un modelo de itinerario bien
construido. Los componentes pueden dividirse en dos categorías, componentes
requeridos y componentes opcionales. Todos los componentes del modelo de itinerario,
representan conceptos, comportamientos, atributos, y buenas prácticas del itinerado. La
conformidad del modelo de itinerario es verificada al evaluarse la existencia y
utilización de los diversos componentes definidos en la lista de componentes. Todos los
componentes requeridos deben ser captados y aplicados en su totalidad para alcanzar un
nivel mínimo aceptable de conformidad. Una vez que el mínimo nivel de conformidad
ha sido logrado, se alcanzan mayores niveles de conformidad con la utilización de los
componentes de itinerario opcionales. Como regla general, el uso de los componentes
opcionales se esperará encontrar en modelo de itinerario más avanzados. Los modelo de
itinerario que no empleen completamente a los componentes requeridos y sus conceptos
son considerados de desarrollo y se evaluarán como que no alcanzan un mínimo de
estándar de conformidad.

El proceso de conformidad del modelo de itinerario se designa para soportar la

evaluación manual. Este proceso evalúa al modelo actual buscando marcadores e
indicadores de componentes específicos para determinar qué componentes específicos
están presentes. Cuando un componente está presente en el modelo de itinerario, se gana
un punto. La relación de cantidad de puntos ganados en relación al total de puntos
posibles representa el nivel de conformidad y se expresa como un porcentaje en la
continua de 0 a 100. La excepción a esta regla involucra a los componentes requeridos.
Como se mencionó anteriormente, si los componentes requeridos no son utilizados
íntegramente, el modelo de itinerario no logrará el estándar mínimo de conformidad. Sin
embargo, el asesor debe continuar con la evaluación por propósitos únicos de
necesidades de desarrollo. En este caso, a pesar de la cantidad de puntos sumados más
recientemente, el modelo de itinerario no marcará en la continua debido a que no
satisface los estándares de conformidad mínimos. Si el umbral mínimo es alcanzado,
entonces el valor de la relación es representado en la continua, o escala móvil, la cual
mueve hacia arriba de izquierda a derecha con el lado izquierdo siendo el más bajo (0) y
el derecho, el más alto (100).

3.5.1 Proceso de evaluación de la conformidad:

Utilizando una lista de componentes de itinerario organizados en componentes

requeridos y opcionales, el asesor podrá determinar si cada componente requerido está
presente en el modelo de itinerario en análisis. El itinerante deberá asegurarse de

53
comprender las buenas prácticas asociadas con dichos componentes. Si el componente
‘requerido’ en particular y cualquier buena práctica necesaria asociada están presentes
en el modelo de itinerario, entonces se consigue un único punto. Cabe destacar que
todos los puntos asociados con el componente requerido deben ser ganados antes que el
asesor pueda registrar un puntaje de conformidad. Luego, el asesor revisará los
componentes opcionales listados y, si están presentes, dará puntaje del modo indicado.
Cada componente opcional tiene también un valor de uno, a pesar que son considerados
como más complejos. El asesor determina un puntaje en bruto al sumar todos los puntos
ganados. Si todos los puntos asociados con los componentes requeridos no son
obtenidos, entonces el puntaje bruto final no se podrá registrar. Finalmente, el puntaje
bruto es dividido por el máximo puntaje total posible. El valor resultante es expresado
en porcentaje, el cual representa la conformidad con el modelo de itinerario.

La utilización de los componentes opcionales más avanzados, sin la utilización

completa de todos los componentes requeridos, ubica la validez de todo el modelo de
itinerario en cuestión. Por ello, si los componentes requeridos no son utilizados
completamente, el proceso de evaluación de conformidad debe ser finalizado.

Así el intento básico de evaluar la conformidad de un modelo de itinerario ha sido

conseguido y el asesor ha determinado en dónde un modelo de itinerario falla en la
continua de conformidad. El itinerante puede entonces determinar acciones específicas
para mover más allá sobre la continua de conformidad, si lo desea o garantiza. Es
reconocido que algunos modelos de itinerario emplearán componentes de itinerado más
avanzados que otros, pero todos deben de suplir unos requerimientos mínimos. Es la
premisa de este texto que a mayor conformidad del modelo de itinerario en uso, mayor
será la probabilidad de desempeño mejorado del itinerario. Un punto final de claridad es
que es la intención de la evaluación el determinar la presencia de un componente, pero
no su utilización, dado que evaluar la utilización puede introducir subjetividades en una
evaluación nada más que objetiva de conformidad con el modelo de itinerario.

54
CAPÍTULO 4: ESTÁNDAR PRÁCTICO PARA LA
GESTIÓN DE LA CONFIGURACIÓN DEL PROYECTO

4.1 INTRODUCCIÓN:

El Project Configuration Management (PCM) es el órgano colectivo de procesos,

actividades, herramientas, y métodos utilizados para manejar ciertos elementos durante
la vida del proyecto, los cuales se denominan elementos de configuración o
Configuration Items (CIs). La gestión de configuración describe los mecanismos para
administrar el estado físico de dichos elementos durante su ciclo de vida. Como con
cualquier otra profesión, este conjunto de conocimientos recae sobre los profesionales
que lo aplican y desarrollan. Los objetivos que se incluyen en la gestión de
configuración son:
• Explicar los conceptos y beneficios de la gestión de configuración en el contexto
de gestión de proyectos.
• Describir los tipos de procesos usados para aplicar la gestión de configuración
como una herramienta de gestión de proyectos.
• Presentar buenas prácticas en gestión de configuración en el contexto de gestión
de proyectos.
• Promover un lenguaje común para poder aplicar la gestión de configuración
entre proyectos.

4.1.1 Propósito del estándar para PCM:

Este estándar provee una guía para las herramientas y procesos más apropiados en un
sistema de gestión de configuración bien diseñado, de manera que permita a los
administradores del proyecto, programa o portafolio determinar si los controles
apropiados están en lugar. El PCM está diseñado tanto para proyectos técnicos como
no-técnicos, menores y mayores, extranjeros o domésticos, y para proyectos dentro de
cualquier tipo de industria.

4.1.2 Cómo utilizar este estándar:

Este estándar está destinado a dar una orientación a las herramientas y procesos
relacionados al PCM. Como referencia fundamental, este estándar no es global ni
definitivo, y puede utilizarse a discreción por el equipo administrador. Este estándar
identifica y describe un subconjunto de administración de configuración que es
reconocido generalmente como de buena práctica para proyectos, y que es aplicable a la
mayor parte de proyectos la mayor parte del tiempo. A su vez cabe resaltar que este
estándar no es un libro de texto, o documento legal o regulador. No es específico para
ningún tipo de industria ni es una guía para la administración de configuración.

4.1.3 ¿Por qué aplicar el PCM?:

Una gestión de proyectos efectiva requiere de procesos consistentes y repetibles (o

metodologías) para poder gestionar las restricciones de alcance, tiempo, costos, y
calidad, y asegurar el éxito del proyecto. El administrador del proyecto aplica
administración de configuración o Configuration Management (CM) para dar soporte

55
activamente la dirección e infraestructura del proyecto. El CM, aplicado a lo largo de
todo el ciclo de vida de un elemento de configuración, brinda visibilidad y control de su
rendimiento, y atributos físicos y funcionales. El CM soporte los siguientes aspectos de
todos los elementos de configuración contenidos en cualquier sistema:
• Integridad
• Responsabilidad
• Visibilidad
• Reproducibilidad
• Coordinación
• Controlabilidad formal
• Rastreabilidad

Para lograr los atributos precedentes, el PCM deberá utilizar herramientas consistentes y
reusables. Dentro de los procesos del proyecto de planificación, ejecución y control, el
CM es crítico. Cuando se aplican las técnicas del PCM, se obtienen varios beneficios,
que incluyen:
• Mantenimiento de la integridad de los CIs
• Las interfaces de comunicación son más claras y contienen información
aplicable
• Los registros están disponibles para dar soporte a los requerimientos de revisión
del proyecto o del cliente
• La información histórica respecto a los CIs entregables pueden utilizarse a lo
largo de la vida del entregable
• La integración entre planificación, ejecución, y control de cambios ayuda a
mantener los requerimientos y resultados finales sincronizados
• Asegurar que sólo los cambios aprobados se incorporen a elementos de
configuración revisados

La tabla a continuación ilustra un modo de fallo y análisis de efectos (FMEA) que

soporta el uso del PCM:

Modo de fallo Efecto Causa Control propuesto

Los entregables y los El proyecto no llega a Gestión de Desarrollar e
documentos no satisfacer los configuración implementar un
coinciden, conflicto requerimientos, inconsistente o estándar de gestión
del uno con el otro, compromisos o incorrecta de los de configuración
impacto o solape expectativas de los recursos y productos nueva que se ajuste a
entre ambos, o uso patrocinadores. de trabajo. las necesidades del
inapropiado. proyecto.
Áreas de interés
• Los dominios de productos dentro de proyectos suelen tener PCM para elementos de
dominio específico (como software, diagramas de ingeniería, fórmulas, etc.)
• Los gestores del proyecto necesitan PCM para elementos específicos de proceso (como
planes, contratos, acuerdos, responsabilidades, reportes de estado, tableros, tarjetas de
puntuación, etc.)
• Los artefactos de disciplinas cruzadas presentan problemas especiales porque están
posiblemente sujetos al PCM tanto en dominio específico como en métodos del proyecto.
Tabla 7: Análisis de efectos del PCM

56
4.1.4 Puntos clave:

La planificación de CM suele ir más allá de los límites del proyecto para asegurar la
coordinación del proyecto con su entorno, y la integración del proyecto en una
aplicación mayor si fuera necesario. Estas consideraciones externas deben ser
documentadas como parte de los requerimientos del proyecto en sus primeras epatas
para asegurar que la integración sea dirigida, planeada, y documentada. El PCM
requiere de interfaces humanas y de sistemas con otros procesos de proyectos para
asegurar que los planes y prioridades del CM se alineen con aquellos del plan de
proyecto mayor. Se deben de definir claramente las interfaces del proyecto para
asegurar una efectiva y eficiente comunicación entre patrocinadores, proveedores,
clientes, y sistemas que sean necesarios para la integración de los requerimientos del
CM y su conformidad.

El PCM otorga una perspectiva proactiva a los procesos de gestión de proyectos

interdependientes de inicialización, planificación, ejecución, control y cierre. Esta
perspectiva dirige la planificación para cambios dentro de todos los procesos de gestión
de proyectos con la mayor antelación posible. El CM es una práctica bien establecida en
varias disciplinas, sin embargo los proyectos son esfuerzos interdisciplinarios, y las
disciplinas específicas tienen comúnmente sus propias estrategias de gestión de
configuración y procedimientos. Un desafío para el administrador del proyecto es
planificar y ejecutar el PCM en los CIs de los proyectos mientras se familiariza con las
necesidades del CM y las capacidades de todas las disciplinas comprometidas en el
proyecto. Controlar los cambios de las líneas base del proyecto es una función
fundamental del PCM. Al comienzo en la planificación, el equipo del proyecto debe
determinar los elementos del proyecto que necesiten de CM y los procesos para
gestionarlos.

A algunos proyectos se les puede requerir mantener la información de configuración

bajo controles muy estrictos debido a un gobierno o regulación industrial; en dichos
casos, circunstancias externas o políticas organizacionales establecen los procesos y
normas que seguirá el proyecto. Estos procesos y políticas son descritos en los planes de
proyectos, específicamente en la documentación que describe el sistema de control de
cambios. El PCM asegura reportes de revisión, sumarios, listas de revisión, estado de
elemento de acción, entregables, y otra documentación relacionada es recopilada y
disponible de manera rápida e informativa para los patrocinadores, administradores del
proyecto, y expertos en el tema, para que sean revisados en cualquier momento para
determinar el estado del proyecto.

4.2 PLANIFICACIÓN DE LA ADMINISTRACIÓN DE CONFIGURACIÓN:

En el libro del PMBOK se identifican herramientas que son utilizadas para llevar a cabo
el proyecto satisfactoriamente. Dichas herramientas (tales como la cartera de proyecto,
la línea base del proyecto y el registro de control de cambios del proyecto) proveen una
base para, y un registro para, el desempeño en lograr el alcance, tiempo, coste, y
calidad. Estas herramientas identifican y proveen para las evaluaciones de impacto de
cambios del alcance planeado, itinerario, y presupuesto a medida que el proyecto
avanza. Las herramientas fomentan las comunicaciones para asegurar que los resultados
del proyecto satisfagan las necesidades de los patrocinadores. El CM es una disciplina

57
que ayuda a asegurar que la funcionalidad post-proyecto es planificada y documentada.
Los requerimientos del PCM pueden variar por proyecto desde esfuerzos mínimos hasta
el propósito principal del proyecto, por ejemplo:
• Un incremento en la máxima velocidad de una carretera local requiere que un
proyecto reemplace diez señales de límite de velocidad. El esfuerzo del CM
estará limitado a identificar las señales que requieren cambio y actualizar el
inventario para reflejar el cambio.
• El dueño de un nuevo lavado de carro necesita que un proyecto construya la
instalación. El esfuerzo del CM incluye desarrollar una lista de equipamientos
maestra identificando cada componente físico en la instalación (incluyendo
identificación de partes, proveedores aprobados, requerimientos de
mantenimiento e itinerario, e historial de mantenimiento), así como gestionar el
desarrollo de la instalación.
• Los cambios en las costumbres de comida de los clientes requiere que un
proyecto desarrolle la capacidad de reubicar constantemente las repisas, la
refrigeradora, y el espacio de la congeladora. El esfuerzo del CM incluye en este
caso la planificación y el proporcionado de sistemas de rastreo automatizados
que integren y optimicen las ventas de productos y se ingenien con el espacio
disponible para poder mostrar el producto.

Para un proyecto independiente sin clientes (por ejemplo, contribuyentes o usuarios de

la aplicación y entregables o elementos resultantes del proyecto), el CM debe de ser un
subconjunto del plan de administración del proyecto.

4.2.1 Organización:

Un proyecto es organizado generalmente con un promotor del proyecto como el único

punto de enlace para los patrocinadores. El promotor generalmente delega los
requerimientos del nivel requerido de CM al equipo del proyecto a través del
administrador del proyecto, y por ende este último es responsable de coordinar los
esfuerzos del equipo para asegurar que el enfoque del proyecto al CM se corresponda
con los requerimientos y expectativas de los patrocinadores. Ésta es una consideración
porque los resultados de un proyecto pueden ser o una interfaz o una entrada para los
sistemas o procesos de configuración propios de los patrocinadores. Nótese que los
patrocinadores también pueden tener tanto procesos como sistemas propios de ellos
mismos.

Para proyectos pequeños o simples en donde no se necesita más que una mínima
planificación, el administrador del proyecto puede actuar también de gestor de
configuración. Para proyectos de mayor envergadura, un gestor de configuración aparte
será necesario para interceder entre el equipo del proyecto y los patrocinadores de
aplicaciones individuales. A nivel de proyecto, las cuestiones del PCM son dirigidas en
un plan de PCM, el cual puede incluir:
• Autoridades, roles, responsabilidades, y disciplinas involucradas
• Identificación de elementos controlados (como elementos de configuración CIs)
• Procedimientos y procesos de control de configuración
• Revisión de estatus y definiciones métricas
• Lista de revisiones y procedimientos de PCM, así como sus relaciones a los
itinerarios del proyecto

58
 Elementos de proyecto Elementos coincidentes Elementos de aplicación
(Dominio del proyecto) (Dominio del proyecto y del (Dominio del producto)
producto)
• Itinerario • Plan de CM • Registros de
• Planes de proyecto • Lista de equipamiento mantenimiento
• Registros de temas maestro • Códigos software
• Revisiones de riesgos • Lista de partes de • Manuales técnicos
• Reportes de estatus repuesto • Registros de
• Elementos de alcance • Control de adquisiciones adquisiciones
• Registros de • Gráficas
modificaciones
• Documentos contables
Tabla 8: Elementos del PCM

4.2.2 Comunicaciones:

Las comunicaciones de calidad y sonoras son elementales para la integración de las

actividades de PCM en el plan de administración del proyecto, y también son un
proceso clave para la gestión de los puntos de interacción del PCM. Una buena gestión
de interfaz es esencial para la comunicación sistemática de la información del PCM y
control de los puntos de interacción.

El PCM requiere de interfaces de sistemas y humanos con otros procesos de proyecto

para asegurar planes y prioridades de la alineación del CM con aquellos del plan de
proyecto general. Las interfaces de proyecto claramente definidas proveen
comunicaciones efectivas y eficientes entre los proveedores, clientes, patrocinadores, y
sistemas. En el PCM, las interfaces de comunicación son categorizadas como interfaces
humanas o de sistemas:
• Interfaces humanas: Cubren las comunicaciones complejas entre personas o
grupos de personas. Para el PCM, las interfaces humanas se categorizan como
internas o externas. Las interfaces internas son aquellas entre personas
comprometidas en el proyecto y las actividades, las cuales pueden ser formales y
documentadas como informales. Las interfaces informales como mínimo deben
ser seguidas comunicaciones sobre las discusiones para verificar que
efectivamente haya acuerdos respecto a las conclusiones de la discusión y
asegurar que se documente un historial de dicha discusión. Las interfaces
informales se desarrollan a medida que los miembros aprenden a impedir y
solucionar problemas por medio de comunicar la información. Las interfaces
externas involucran comunicación entre el equipo y personas externas, y dichas
interfaces se pueden dar con patrocinadores, proveedores, y organizaciones de
soporte. Otras interfaces externas pueden ser con los usuarios finales afectados
por los cambios relativos al PCM definido. Definir las interfaces externas provee
un medio para los métodos de comunicación y canales para integrar a los
usuarios finales externos dentro del proceso de cambio.
• Interfaces de sistemas: Las interfaces de sistemas son los artefactos creados para
compartir datos entre sistemas, y entre sistemas y humanos, se definen por
procesos y son descritas en documentos como plan de gestión de alcance del
proyecto. Las interfaces de sistemas también se encargan de los procesos y
estructuras en establecimiento que aseguren conformidad con los estándares y
regulaciones. En la mayoría de proyectos, las interfaces de sistemas se ocupan
59
 de los varios estándares y procesos de CM de aplicación específica relacionados
a las disciplinas en práctica.

4.2.3 Entrenamiento:

En algunos casos, los proyectos complejos requieren de entrenamiento formal para que
los patrocinadores comprendan las necesidades, requerimientos, desarrollo, y
mantenimiento de un plan de PCM y actividades relativas.

4.2.4 Gestión de configuración y PCM:

Los proyectos suelen ser esfuerzos de disciplinas cruzadas, las disciplinas específicas
tendrán generalmente sus propias estrategias y procedimientos de CM. Un reto para el
administrador es planificar y ejecutar el CM en los CIs del proyecto a la vez que se
armonizan las necesidades del CM y las capacidades de todas las disciplinas
comprometidas en el proyecto. El término ‘armonización’ se usa para describir una
condición en donde los sistemas de gestión de configuración de un proyecto gestionan
CIs únicos; no están en conflicto en práctica, itinerario, o uso de recursos; y comparten
léxico y vocabulario necesario para comunicaciones de interfase efectivas entre
patrocinadores.

4.3 IDENTIFICACIÓN DE LA CONFIGURACIÓN:

A lo largo de la duración de un proyecto es necesario manejar la información para

gestionar al proyecto, y por ello crear, modificar, y almacenar esta información es una
parte muy importante. La identificación de la configuración ayuda a identificar en un
proyecto aquello que puede ser puesto bajo el control del PCM.

4.3.1 Artefactos del proyecto:

Desde el comienzo de un proyecto, los documentos y otros artefactos son creados para
ayudar a la gestión del proyecto y proveer comunicaciones al equipo, patrocinadores,
administradores, entre otros. Algunos documentos y otros artefactos describen al
proyecto en sí y a sus características, por ende, el documento del proyecto expone qué
pretende llevar a cabo, y las definiciones de requerimientos identifican las capacidades
esperadas del entregable final. Existe información adicional que expone las relaciones
acordadas entre las diversas organizaciones que son parte del proyecto o lo apoyan.
También se puede incluir los contratos con los distribuidores, subcontratados,
proveedores, así como los acuerdos de apoyo con otros grupos dentro de la misma
organización.

Una lista con ejemplos de la información que pueden estar bajo el control del PCM:
• Cambios de información
• Contratos
• Artefactos de costos
• Invitaciones a pujas
• Métricas
• Estructura de subdivisión de la organización
• Documentos de planificación

60
 • Plan de gestión del proyecto
• Plan de calidad
• Registro de riesgos
• Información de itinerario
• Declaración de trabajo
• Estructura de subdivisión del trabajo

Esta lista no debe considerarse como información requerida para todos los proyecto, por
el contrario, únicamente otorga una ilustración de los posibles documentos para una
variedad de proyectos. La colección efectiva puede variar de un proyecto a otro, y como
en toda posibilidad incluye sólo un grupo pequeño de estos, así como elementos
adicionales que son específicos para un proyecto en particular o política organizacional.

4.3.2 Estructura:

Como con cualquier información importante, se requiere un método de estructuración

de documentos y artefactos bajo el PCM. El requerimiento más básico de estructurado
es de un sistema de archivos que haga posible organizar la información para un
almacenamiento, recuperación y uso eficiente. También abarca otras necesidades, como:
• Formato de la información: Puede ser de dos tipos: electrónica o en papel; y
ambas requieren de estructurarse adecuadamente para el proyecto. Apenas de
que los métodos utilizados difieren, el objetivo es el mismo: hacer posible la
gestión eficiente de los documentos y artefactos del proyecto con el balance
adecuado de accesibilidad, seguridad, recuperabilidad e indexado de
almacenamiento.
• Acceso rápido: Es importante que la información usada frecuentemente por el
equipo sea fácilmente accesible, y para facilitarlo, algunos administradores
crearon lo que llaman la ‘encuadernación’ del proyecto (tanto para formato
electrónico como papel). Dicho encuadernado contiene elementos como planes
de proyecto y de personal, información de contactos, reportes, información de
presupuestos, entre otros.
• Disponibilidad extensa: Es importante que la información manejada por varios
miembros esté en una localidad de fácil acceso; un método típico es el tener la
información en ficheros digitalizados con un seguro acceso a red, los cuales
permiten a todo el equipo acceder a ellos de rápidamente de cualquier localidad
con ordenador, incluyendo Internet. Este punto es particularmente importante
para un proyecto en el que el equipo está disperso geográficamente. Se debe
tener cuidado al administrar la actualización, agregado o borrado de información
para asegurar que únicamente los cambios autorizados sean permitidos y que
éstos se realizan sobre la versión correcta del artefacto.
• Acceso seguro: Puede haber información restringida, por lo que se deben usar
controles para limitar el acceso únicamente a aquellos que necesitan de la
información. Los datos sobre el presupuesto y el personal así como algunas
correspondencias requieren de un tratamiento especial para protegerlos. Los
controles de acceso propiamente implementados pueden ayudar a asegurar la
integridad de información.
• Recuperación de la información: Un elemento importante del plan de
almacenamiento de datos es el plan para recuperación de cualquier documento o
artefacto que sea extraviado o haya quedado inaccesible. Un plan de
recuperación define cómo se realizan copias de seguridad de los artefactos del
61
 proyecto, cuándo y con qué frecuencia, y el proceso de recuperación para cada
elemento.
• Retención de la información: Ocasionalmente, surgen situaciones en donde la
información antigua que fue reemplazada con información más reciente, necesita
ser consultada. Un plan para conseguir versiones antiguas de información para
consultas futuras puede ser útil en algunos proyectos.

Para varios proyectos, sobre todo los grandes en donde se espera producir bastante
documentación, puede ser de beneficio tener pensado un plan de documentación. Un
plan de documentación diseña los detalles sobre cómo se debe estructurar y gestionar la
documentación, y se desarrolla usualmente al comienzo del proyecto. El plan deberá
identificar lugares para el almacenamiento de la documentación. Para los documentos
que van a estar bajo constantes revisiones, el plan también contempla la progresión para
versiones del documento desde el comienzo hasta su uso, y desde su actualización hasta
su archivado. También señala cualquier cambio en los lugares de almacenamiento a
medida que el documento progresa de un estado al otro. El plan de documentación debe
de ser fácilmente accesible al equipo así como a cualquier persona autorizada para
rellenar documentos nuevos o cambiados, no obstante el acceso debe estar de acuerdo a
las políticas de seguridad y privacidad de la organización. Una vez creado, el plan de
documentación debe ser puesto bajo el PCM.

4.3.3 Identificación de elementos:

La identificación de configuración es una estructura organizada que describe la

composición de objetos dentro de un proyecto, dichos objetos son denominados CIs.
Las descripciones de línea base estándar de los atributos físicos y funcionales de estos
CIs se establecen para mantener control de los cambios que ocurren a los elementos
existentes y nuevos ‘elementos terminales’ o entregables dentro de los proyectos.

Generalmente, los procesos del proyecto resultan en establecer líneas base aprobadas y
descripciones relacionadas de manera oportuna. Cualquier cambio de las líneas base son
documentados por su efecto en elementos únicos y son aprobados. Las líneas base
reflejan las diferencias entre ‘como planeado’ sobre el ‘como salió’.

La identificación de elementos de configuración enfatiza los entregables finales del

proyecto así como eventos significantes o efectos, y presenta tanto al administrador y
cliente como al sponsor con puntos reconocibles de logros. Los elementos escogidos del
proyecto son a un nivel suficientemente significativo para mantener el control y puede
consistir en elementos físicos, documentos, cédulas, y registros. Estas cuatro categorías
pueden ser subdivididas por tipo y línea base. Como ejemplo de elementos
significativos están:
• Elementos que deben cumplir requerimientos legales
• Elementos que deben cumplir pautas de salud y seguridad
• Elementos a ser enviados a subcontratados
• Elementos que tienen un impacto en procesos o entregables fuera del proyecto
• Elementos que forman un componente extenso del entregable del proyecto

4.3.4 Esquema de taxonomía:

62
Los procesos formales de revisión, seguimiento de estatus, y gestión de los cambios
requiere que la información que describe un CI sea diferenciada de la información que
describe a otras CIs. En la práctica, los proyectos encontraron que los CIs deben ser
únicamente identificados para control, procesado y seguimiento. La identificación única
puede lograrse asignando números seriales, números no significativos o cualquier
clasificación establecida y aprobada para cada CI.

Con el uso del lenguaje en un identificador se demostró que se reducen los errores de
identificación y permiten facilidad en el uso, y por ende la tendencia es el uso de una
mezcla de letras significativas (como son el tipo de CI, la fecha, versión, etc). La
complejidad y sofisticación necesarias para un sistema de catalogación refleja el tamaño
y relaciones de un proyecto, por lo que si un sistema es más complejo, se le deberá
asignar más tiempo, recursos, y presupuesto a la porción de CI y esquemas de
taxonomía. Dependiendo del tipo de proyecto y políticas corporativas, se pueden
considerar los siguientes tipos de identificadores:
• Especificaciones de referenciado de identificadores inteligentes mediante la
inclusión dentro del código de ID:
o Categoría del elemento (físico, documento, cédula o registro)
o Asociación jerárquica a otros elementos (programas, especificaciones de
sistemas)
o Control de versión (original, mejora, cambio completo, subcontratado o
manufacturador, ubicación de la planta)
• Sello de fecha
• Fuente del elemento (proyecto, subcontrato, elemento existente de la compañía)
• Formato (si es digital, el software de procesado, versión, y plataforma)
• Serialización o control de lotes

4.4 GESTIÓN DE CAMBIOS DE LA CONFIGURACIÓN:

El libro del PMBOK define a la gestión de configuración (CM) como un subsistema

dentro de la administración global del proyecto. Los procesos en el PCM se utilizan
cuando se administran las principales limitaciones del proyecto como son las del
alcance, tiempo, costo, y calidad. La gestión de cambios de configuración o
Configuration Change Management (CCM) juega un papel crucial al administrar dichas
limitaciones, al abarcar los procesos y procedimientos utilizados para gestionar los
cambios a los CIs. Aplicar los principios de CCM a los artefactos del proyecto asegura
un número de beneficios que incluyen:
• La versión correcta del CI está siendo usada por el equipo
• Las cambios a los CIs se hacen únicamente por gente autorizada
• Un medio planeado de notificar a los patrocinadores que los cambios aprobados
de los CIs está en lugar
• Un registro de cambios de los CIs es guardado para apoyar las revisiones y
actividades de cierre del proyecto

El CCM se aplica para identificar y documentar cambios y sus impactos en los CIs,
dichos cambios luego son procesados a través del sistema de control de cambios del
proyecto. En varias áreas de aplicación el sistema de control de cambios es un
subconjunto del sistema de gestión de configuración. Las fases individuales del proceso
de gestión de cambios de la configuración se describen de la siguiente manera:

63
 • Línea base: Ésta es la última línea base emitida por el CM.
• Petición de presentación del cambio: Este paso prepara la petición, asegurando
que se provee de la información adecuada para permitir una correcta revisión del
impacto del cambio.
• Petición de verificación del cambio: Este paso asegura que toda la información
necesaria para llevar a cabo una evaluación ha sido provista. Establece
relaciones entre los cambios propuestos y los elementos que serán impactado por
el cambio.
• Evaluar los impactos: Este paso evalúa el impacto del cambio propuesto. Se
evalúan todos los tipos de impactos, como el técnico, costo, itinerario,
seguridad, y contrato. Identificar la gente apropiada para llevar a cabo la
evaluación puede ser difícil. Lo necesario para asegurar que todos los impactos
son identificados deben balancearse con los necesarios para ejecutar el proceso
eficientemente al realizar únicamente las evaluaciones necesarias.
• Revisión de decisiones y del plan: Este paso considera el cambio propuesto en
vista del impacto evaluado. La autoridad requerida para aprobar un cambio
variará en función del tipo y estatus de los elementos afectados, pero por
supuesto, un cambio propuesto también ser rechazado. Los elementos que
realmente necesitan ser cambiados son confirmados y se establecen y/o ajustan
paquetes de trabajo.
• Implementar cambio si es aprobado: Este paso hace la diferencia, rastrea el
progreso, y reporta estatus al sistema de seguimiento. Las relaciones entre el
registro de cambios y el o los elementos actualmente afectados por el cambio
son establecidas y actualizadas.
• Conclusión del proceso de cambio: Este paso asegura que el proceso de CM ha
sido correctamente seguido y que hay evidencia apropiada que los cambios
fueron implementados satisfactoriamente. La autoridad para concluir un cambio
es la misma que para probarlo. El estatus es reportado al sistema de seguimiento.

4.4.1 Identificación:

El libro del PMBOK sugiere que una clara distinción hecha entre planes y líneas base de
medición de rendimiento del proyecto. Específicamente, define planes como entregables
que se esperan vayan a cambiar con el tiempo y manifiesta que las líneas base de
medición del rendimiento cambien sólo en respuesta a alcances de trabajo aprobados o
cambios en los entregables. La identificación de los entregables del proyecto como los
CIs pueden ser formales o informales. El nivel de formalidad, la complejidad del
proceso CCM, y el costo de apoyar los procedimientos deben adecuarse a las
necesidades del proyecto.

El CCM es usualmente descrito en el plan de control de cambios del proyecto o en un

plan de CM separado si el tamaño y complejidad del proyecto lo justifican. Idealmente,
El proceso de CCM es descrito en un documento y escalable al proyecto. Por último, el
CCM deberá ser legiblemente visible a los patrocinadores para que las limitaciones (de
alcance, tiempo, costo, y calidad) puedan ser gestionadas con éxito.

4.4.2 Proceso:

El proceso de gestión de cambios describe el control de cambios integrado como un

sistema que cubre la creación y evaluación de valores de las peticiones de cambio.

64
Adicionalmente, el proceso de gestión de cambios incluye el mantenimiento de líneas
base y gestión de los cambios. En algunos sistemas, la autorización para realizar
cambios o modificar documentos es rastreada, y en otros sistemas dicha autorización es
controlada electrónicamente a través de accesos de seguridad. El CCM abarca los
procesos utilizados para gestionar cambios a los CIs. Un proyecto debe tener un número
de procesos de gestión de cambios.

El CCM puede ser gobernado por estándares de la industria o práctica. Los sistemas y
componentes de CCM han sido desarrollados para algunas prácticas, como manufactura,
desarrollo de software, y construcción. Un proceso de CCM puede incluir un número de
componentes y un flujo estructurado de proceso. El flujo estructurado de proceso
describe las actividades, entradas, salidas, y controles para cada paso de un ciclo de vida
de un proceso de cambio. Los componentes del CCM son mecanismos que dan soporte
al proceso de CCM, por ejemplo una base de datos enlistando información sobre los CIs
es uno de dichos componentes. Una cédula de petición de cambio es otra forma.

Un proceso de CCM tiene procesos y procedimientos que sirven para asegurar que
todos los aspectos necesarios de la gestión de cambios de configuración son dirigidos y
las decisiones son reflejadas con precisión. El proceso de CCM responde a una cantidad
de propósitos además de prescribir procedimientos administrativos. Por ejemplo, el
proceso ayuda a asegurar:
• Los puntos de vista de los patrocinadores son dirigidos
• Los impactos en el alcance, tiempo, costo, y calidad son identificados y
documentados
• El personal asignado conduce las evaluaciones
• Las recomendaciones y aprobaciones son buscadas y registradas
• Las decisiones son comunicadas por medio de interfaces humanas internas y
externas apropiadas.

Es importante recordar que el proceso de CCM requiere que los procedimientos

relacionados sean documentados y que las líneas base de configuración apropiadas sean
establecidas. Es obligatorio que las líneas base otorguen la identificación y control de
los CIs. En general, la secuencia de eventos para una iteración del proceso de CCM
comienza con la determinación que el cambio es necesario. El impulso del cambio, por
ejemplo, puede ser una mejora, un nuevo requerimiento, la clarificación de un
requerimiento existente, o un cambio ordenado externamente. La documentación del
proyecto establece responsabilidades y procedimientos para documentar las necesidades
del cambio, así como procedimientos para enviar una petición de cambio. Nótese que el
proceso de control de cambios tiene las herramientas y técnicas necesarias para el envío,
registro, y almacenamiento de las peticiones. El proceso de CCM es un tipo de carga de
trabajo, en donde el primer grupo de actividades involucra el reconocimiento y
documentación de un cambio necesario y la entrada de dicha información en el sistema
de gestión de cambios.

El siguiente grupo de actividades está relacionado a la evaluación y aprobación de la

petición de cambio. Estas actividades y su secuencia pueden ser complejas si varias
organizaciones y/o una cantidad enorme de documentación están envueltas.
Generalmente, la evaluación incluye una revisión por una configuración o una tabla de
control de cambios (Change Control Board o CCB) o equivalente. El siguiente grupo de
actividades incluye a las relacionadas con procesar los resultados de la evaluación y

65
actividades aprobadas. Dichas actividades incluyen otorgar notificaciones, prepararse
para la implementación de los cambios aprobados, implementar los cambios, y validar
que los cambios se hicieron efectivos. Nótese que en algunos proyectos, la verificación
del cambio es realizada por un elemento operativo, y un elemento organizacional por
separado posteriormente verifica la implementación.

4.4.3 Control:

El control fundamental de cambios de elementos de configuración (CIs) puede lograrse

a través del sistema de información de administración del proyecto o Project
Management Information System (PMIS), el cual soporta un seguimiento de revisión
completo y el reporte de peticiones de cambio. Las peticiones contienen información
adecuada para gestionar cambios a los entregables. Dependiendo del área de aplicación
y en el nivel de complejidad del entregable, el PMIS puede ser incrementado o
complementado por una base de datos de CI.

Los controles formales de los CIs tienden a centrarse en un único entregable siendo
producido. Las áreas de aplicación como la arquitectura, ingeniería, construcción,
manufacturado, y sistemas informáticos son frecuentemente gobernadas por estándares
industriales o pautas de práctica formales. El control de gestión de cambios, siendo
formal o informal, asegura que cada petición de cambio sea seguida en toda su duración.
El rastreo normalmente debería incluir lo siguiente como mínimo: Un número único de
rastreo, información iniciadora, sello de tiempo, y un resumen de la petición.

4.4.4 Revisión y aprobación:

El administrador del proyecto tiene la responsabilidad definitiva por la integridad del

proceso de petición de cambio, y por el trabajo de rastreo en la implementación de la
resolución de la petición de cambio aprobada. La responsabilidad por las aprobaciones y
denegaciones de una petición de cambio es establecida en los documentos de proceso
del proyecto. Dicha responsabilidad debe ser asignada a un patrocinador técnico
cualificado a cualquier nivel en la jerarquía.

La carta del proyecto u otros requerimientos pueden imponer requerimientos de

información de control de cambios en un proyecto. Esto se puede esperar cuando un
proyecto es parte del un programa con proyectos relacionados. Los puntos de jerarquías
de contacto son más complejos para los programas que para los proyectos. El nivel de
esfuerzo para el CCM de un programa se espera que sea mayor que para el CCM de un
proyecto. Si el contrato se aplica, los patrocinadores clientes y legales deben estar
incluidos en el punto de jerarquías de contacto. Se puede esperar que esto incremente el
nivel de esfuerzo. Dichos patrocinadores deben tener autoridad de rechazo de peticiones
de cambio, en función de la naturaleza del contacto y el nivel de exposición al riesgo y
la tolerancia al mismo.

4.4.5 Implementación:

Algunos requerimientos básicos para implementar cambios en el CI son:

• Aprobación documentada
• Uso de las técnicas y herramientas de CM adecuadas para el área de aplicación

66
 • Documentación de las mediciones de calidad reveladoras y resultados de
pruebas adecuados para el área de aplicación

4.4.6 Verificación y Aceptación:

La verificación y aceptación de una resolución de petición de cambio es lograda

únicamente después que la autorización de un apropiado patrocinador técnico o de
negocios es obtenida. En algunos casos, las pruebas formales o aprobación regulatoria
es requerida antes que un cambio sea aceptado. La verificación y aceptación aseguran
que solamente los cambios autorizados son implementados.

4.4.7 Cierre:

La autoridad de un apropiado patrocinador técnico o de negocios, reconociendo la

implementación satisfactoria de una resolución de petición de cambio aprobada dentro
de unos límites de alcance, tiempo, costo, y calidad relevantes, es tanto necesaria como
suficiente para el cierre de la petición de cambio. Un entregable no debe considerarse
completo hasta que todas las peticiones de cambio que influyen en un entregable sean
cerradas.

4.5 MEDICIONES Y REVISIÓN DEL ESTATUS DE LA CONFIGURACIÓN:

Las mediciones y revisiones del estatus de la configuración sirven para mantener y

reportar información acerca de los elementos de CM y acciones relacionadas, como los
cambios pendientes. Un proyecto puede utilizar el estatus y las revisiones de la
configuración para difundir información, validar y verificar acciones, y servir de
mecanismo de retroalimentación para el proceso global del PCM.

4.5.1 Depósito de información:

Los depósitos de información son un aspecto esencial para el PCM. Un depósito de

información es un lugar (base de datos, librería, o sistema de archivos) en donde la
información del proyecto se guarda para un almacenaje, acceso, versión, y control de
versión controlados. Un proyecto puede tener uno o más depósitos. El plan de PCM
puede describir los repositorios y los procesos para su uso. El plan de PCM puede
también mostrar las relaciones e interfaces entre los depósitos, sus procesos, y la gente
que lo utiliza. La revisión de estatus de la configuración o Configuration Status
Accounting (CSA) involucra la adquisición e ingreso de información en el depósito en
aplicación. Para ingresar y luego localizar información, ha sido útil el organizar el
depósito sistemáticamente. El WBS, OBS, o jerarquías de documentos son ejemplos de
maneras de organizar las estructuras de depósitos.

Basándose en la información recolectada, se desarrollan una serie de mediciones para el

análisis. El CSA otorga los datos necesarios para verificar si los cambios aprobados han
sido consistentes con los objetivos del proyecto y pueden ser rastreados con el alcance y
su evolución. Esta depósito de datos incluye varios puntos de referencia, líneas base y
medidas de niveles de producción, en conjunto con el historial de niveles de revisión
para todos los hardware, software, y documentación.

67
4.5.2 Reporte:

El CSA y los reportes de mediciones producen información de administración para el

proyecto. Esta información puede utilizarse para comparar una medida de nivel de
producción contra la línea base, controlar los cambios de esta medición, y rastrear
cualquier mejora que la medición otorgue al proyecto en el tiempo. Una vez establecida
la línea base de medición de nivel de producción, se pueden producir reportes de
seguimiento periódico en las actividades de CM, la calidad del proyecto, y desempeño
medido en el tiempo:
• Estatus: El estatus en el contexto del PCM requiere que el PCM tenga el control
sobre los CIs, puedan mostrar unos datos de revisión y los artefactos de todos los
cambios incluyendo todas las versiones de los CIs, y mostrar el estatus de cada
versión. El estatus de un cambio en el CI debe indicar su etapa en el ciclo de
vida, como borrador, en revisión, aprobado, no efectivo, efectivo, retirado, o
obsoleto. El estatus indica también si los cambios están pendientes de un CI. El
nivel de detalle y el control es relativo al riesgo, regulaciones, y estándares. Por
ejemplo, se espera que gasten más recursos en mantener controles estrictos y
registros del alcance que en los minutos de una reunión semanal de equipo de
proyecto. Las revisiones de estatus rastrean el estatus de los cambios aprobados.
Como tal, la revisión de estatus del PCM sirve como mecanismo de control para
informar al administrador del proyecto sobre los resultados de un cambio
aprobado. El estatus de cada CI se determina en concordancia con los procesos
de CCM. La coordinación y comunicación son esenciales para asegurar que los
cambios que son planeados y los datos a ser seguidos dentro de un cambio dado,
se identifican con suficiente antelación. Un plan de colección, aún si se trata sólo
de una simple lista, ayuda a asegurar que se capturan los datos suficientes. Los
datos necesarios pueden incluir qué CIs son dirigidos en revisiones técnicas y de
verificación, para que la información de estatus requerida se provea a tiempo de
acuerdo al plan del proyecto. Otra posible petición de estatus puede ser para
reportar el número de peticiones de cambio enviadas, y de dichos envíos,
cuántas fueron rechazadas y porqué.
• Mediciones: Las mediciones son una herramienta de comunicación utilizada por
el administrador del proyecto para evaluar el control del proyecto y determinar si
se requieren de mejoras en los procesos. Las mediciones rastrean qué se ha
cambiado, cuando fue cambiado, y qué impacto tuvo el cambio, si lo tuvo, en los
datos capturados previamente y sus potenciales efectos en los nuevos datos.
Estos registros deben incluir suficiente detalle para permitir el análisis e
investigación de los procesos que pueden inestabilizarse después de realizado el
cambio. El grupo óptimo de mediciones y su grado de granularidad depende de
las estrategias, recursos, tecnologías, y sectores de negocios de la organización.
Algunas mediciones pueden ser medidas en escala temporal o tolerancias, y
otras en costo. Cada medición puede ayudar al proyecto a conseguir satisfacer
las necesidades de sus respectivos patrocinadores. Las mediciones ayudan a
estimar el esfuerzo requerido por los CIs al establecer puntos de referencia para
previos esfuerzos de trabajo similares. Estas estimaciones de esfuerzo pueden
ayudar al administrador del proyecto a identificar tendencias en la productividad
de implementar varios CIs, a determinar si las técnicas de estimación son
válidas, a rastrear la satisfacción del cliente, y rehacer rastreos. Pueden ayudar a
determinar el impacto que puede tener un cambio propuesto, y ello puede a su
vez ayudar a la toma de decisiones. Dichos datos pueden ayudar también a

68
 facilitar la comunicación en el proyecto, desde que los datos de toma de
decisiones están al alcance de todo el mundo. Para máxima utilidad, los datos
deben ser presentados al administrador del proyecto en un formato apropiado
para análisis destacados. Este formato puede incluir valores numéricos,
representaciones gráficas, tablas, o texto.
• Referenciado: Poner puntos de referencia o referenciar en el proyecto involucra
comprar los procesos del proyecto, herramientas, y técnicas, con otros
proyectos. Los otros proyectos pueden estar dentro o fuera de la organización
del proyecto en cuestión. Los puntos de referencia sirven para planificar el PCM
y analizar resultados. La puesta de puntos de referencia es el proceso de capturar
datos de un sistema en funcionamiento; estos datos pueden ser de un sistema de
prueba antes que encuentre algún tipo de carga, o sea capturado de un sistema de
producción similar que alguna aplicación nueva tenga la intención de superar. El
PCM puede también requerir un tipo más especifico de referenciado. El
referenciado puede ser preparado para cualquier aspecto de un sistema,
incluyendo: tiempo de entrenamiento, curva de aprendizaje, facilidad de uso, así
como los elementos de datos normales de tiempo de respuesta, tiempo de
servicio al cliente, y la satisfacción del usuario final. Para el PCM, este tipo de
referenciado produce elementos de configuración que son multipropósitos, los
cuales alimentan los procesos de aseguramiento de la calidad y pueden generar
peticiones de cambios como acciones correctivas basadas en análisis de
varianza.
• Mediciones de desempeño: Las mediciones del desempeño pueden variar
ampliamente en función del tipo de aplicación en desarrollo. Dichas medidas
pueden expresarse como indicadores de desempeño clave o Key Performance
Indicators (KPIs) como:
o Cuantitativo: Esta medición requiere la definición de un grupo de
medidas objetivo que pueden expresarse como una cantidad específica,
como una cantidad, una suma, o un número.
o Cualitativo: Esta medición requiere la definición de un grupo de
características o atributos computacionales específicos del proyecto.
• Entrega de las estadísticas operacionales: Las estadísticas operacionales pueden
incluir los artefactos de control de procesos estadísticos o Statistical Process
Control (SPC) artifacts. Los ejemplos incluyen tablas de control, gráficos de
registros, retroalimentación de los usuarios y clientes, y determinación global en
cuanto a si el cambio lleva al resultado deseado. Las estadísticas operacionales
normalmente otorgan una medición de la repetitividad y reproducibilidad
requerida para la determinación de la estabilidad del proyecto en el tiempo. El
SPC puede utilizarse para medir la estabilidad del proceso sobre el tiempo, y
puede otorgar un referenciado estable para revisar cualquier cambio de datos
después de la implementación del cambio.
• Proporcionar los reportes: Las revisiones de estatus pueden proporcionar
reportes periódicos o ad hoc, dichos reportes son una herramienta de
comunicación que describe tanto la actividad de control de cambios como el
estatus de los CIs. Los reportes pueden proporcionar los siguientes tipos de
información:
o Líneas base:
ƒ Cuándo fueron creadas y por quién
ƒ En dónde se guardó la información, y cómo conseguir acceso a ella.
o Peticiones de cambio:

69
 ƒ Nuevas desde el último reporte
ƒ Peticiones de cambio activas y sus estatus en el proceso de cambio
ƒ Peticiones aprobadas desde el último reporte y acción para
implementar
ƒ Detalles de peticiones rechazadas
o Notificaciones
ƒ Notificaciones de cambio y distribución para las peticiones de
cambios y los CIs afectados
ƒ CIs cambiados
o Estatus de la implementación:
ƒ Cambios siendo implementados y sus estatus
ƒ Revisiones planeadas

4.5.3 Análisis:

El análisis de las medidas de la mejora de un proceso ayuda a determinar si el proceso

de gestión de cambios del proyecto está funcionando de la manera planificada al
mejorar el sistema en global. Las tendencias de los datos pueden utilizarse para
monitorear los niveles de desempeño. Los cambios del entorno, el procedimiento y
equipamiento de medición, y los diversos factores adicionales pueden impactar en los
datos de medición capturados.

4.6 VERIFICACIÓN Y REVISIÓN DE LA CONFIGURACIÓN:

El propósito de la verificación y revisión de la configuración o Configuration

Verification and Audit (CVA) no es otro que el de asegurar la composición de los CIs
del proyecto, y que los camios en los CIs sean registrados, evaluados, aprobados,
rastreados, y debidamente implementados. El proceso de verificación y revisión puede
abarcar lo siguiente:
• Integridad de la información del CI
• Precisión y reproducibilidad de la historia del CI
• Rastreabilidad de los CIs del proyecto a través del proceso de administración del
proyecto así como entre CIs
• Se complete la documentación que define al proyecto

La verificación y revisión del PCM establece que los requerimientos funcionales y de

desempeño de un proyecto y sus entregables han sido alcanzados por el diseño e
implementación del proyecto. La verificación y revisión del PCM se realiza en
versiones de entregables iniciales, provisionales, y finales, incluyendo el caso en que el
CI sea publicado o referenciado.

4.6.1 Verificación:

La verificación del PCM asegura que los objetivos del PCM son logrados a través de
comparaciones sistemáticas de los requerimientos cuando los resultados iniciales,
provisionales y finales de pruebas, análisis, demostraciones o inspecciones.

4.6.2 Revisión:

70
La revisión del PCM es el proceso independiente de asegurar que los CIs del proyecto
se hicieron según su documentación definida. Una revisión no buscar reemplazar
chequeos, pruebas, o inspecciones de los entregables. La revisión del PCM incrementa
la visibilidad del proyecto, compara al proceso actual con el proceso documentado, y
descubre cualquier deficiencia del proceso. La revisión del PCM otorga una herramienta
adicional para ayudar al administrador del proyecto a determinar qué tan bien marcha el
proyecto, para identificar y volver a evaluar riesgos, y solucionar problemas.

La verificación del PCM se suele alcanzar a través de revisiones formales del CM, las
cuales son generalmente conducidas al menos una vez para cada emisión, tales como:
revisión de la configuración funcional o Functional Configuration Audit (FCA), y
revisión de la configuración física o Physical Configuration Audit (PCA). Las
revisiones adicionales del PCM incluyen:
• Evaluar las cantidades de las partes de repuesto y la configuración
• Determinar los componentes del equipamiento instalados actualmente, así como
su configuración
• Revisar y cambiar los resultados del control

4.6.3 Actividades de verificación y revisión:

Las actividades de verificación y revisión del PCM consisten en la planificación,

ejecución, creación de reportes, comunicaciones:
• Planificación de la verificación y revisiones: Es esencial para la verificación y
revisión del PCM estar planificado en cada punto crítico del proyecto, en donde
los principales riesgos de configuración son propensos a ocurrir. Algunas
organizaciones tienen un plan de CM de empresa que establece políticas de CM,
procesos, y procedimientos a utilizar en todos los proyectos. Cualquier plan de
CM de empresa existente debe de adaptarse a las necesidades del proyecto, y
que las verificaciones y revisiones de PCM apropiadas sean programadas.
• Ejecución de la verificación y revisiones: Es esencial para un administrador de
proyecto establecer el tiempo, estructura, y recursos necesarios para realizar las
actividades de revisión y verificación de la manera planificada en el plan de CM
del proyecto o en el plan de administración del proyecto. A través del CM, un
administrador de proyecto requiere asegurar que todos los temas de
recomendaciones y disconformidades sean dirigidos y apropiadamente
programados para su corrección.
• Reporte: Los puntos a continuación identifican los reportes de PCM que un
administrador de proyecto debe esperar del proceso de verificación y revisión:
o Reportes indicando los resultados de la revisión de PCM y la
recomendación de proceder o no a la siguiente actividad o tarea
o Emitir notas indicando los contenidos de la línea base o emisión,
deficiencias conocidas, una lista de componentes y versiones de
componentes, soluciones para otorgar fijas temporales, y lo que ha
cambiado desde la última nota de emisión (incluyendo la identificación
de los reparos), etc.
• Comunicación de resultados de la verificación y revisiones: Un administrador de
proyecto tiene la responsabilidad de comunicar los resultados de la verificación
y revisión del PCM a los patrocinadores apropiados, tal y como se establece en
el plan de comunicaciones del proyecto, o el plan de CM.

71
CAPÍTULO 5: ESTÁNDAR PRÁCTICO PARA LA
GESTIÓN DE RIESGOS DEL PROYECTO

5.1 INTRODUCCIÓN:

De acuerdo con el libro del PMBOK, un riesgo se define como una condición o evento
que si ocurriese, puede tener efectos positivos o negativos en los objetivos del proyecto,
los cuales incluyen al alcance, itinerario, costos, y calidad. La gestión de riesgos, según
el mismo libro, incluye a los procesos relacionados con administrar en un proyecto la
planificación, identificación, análisis, respuestas, monitoreo y control de gestión de
proyectos. Se menciona a su vez que los objetivos de la gestión de riesgos son de
incrementar la probabilidad de impacto de eventos positivos, y bajar la de los eventos
negativos en el proyecto.

En este contexto, la gestión de riesgos de proyectos busca identificar y priorizar riesgos

antes de que estos ocurran, y otorgar a los administradores información orientada a
acciones. Esta orientación requiere considerar eventos que puedan o no ocurrir, y por
consiguiente descritos en términos de posibilidad de ocurrencia, además de otras
medidas como el impacto en los objetivos.

La gestión de riesgos es una herramienta necesaria dado a que en un proyecto siempre

hay posibilidad de que ocurran eventos que puedan cambiar el rumbo del avance, y por
tanto se debe incluir en los planes del proyecto. Varios procesos propios de la gestión de
proyectos, que están relacionados con la planificación, asumen grados de certeza poco
cercanos a la realidad y por ello deben ser incluidos en los tratamientos de los riesgos.

La gestión de riesgos trata con las incertidumbres en las estimaciones y suposiciones del
proyecto; la planificación del proyecto otorga fechas y caminos críticos basados en
duraciones y disponibilidades asumidas exactas, entonces un análisis de riesgos
cuantitativo explora la incertidumbre en las estimaciones y da valores alternativos o más
realistas, según el riesgo en el proyecto.

No se puede concebir a la gestión de riesgos como sustituto de otros procesos de

administración de proyectos; lo que hace la gestión de riesgos es tomar los valores de
las salidas de cada uno de estos procesos y modificarlas tomando en cuenta los riesgos
propios de cada uno.

Cuando se empieza un proyecto, se tiene el caso de máximo riesgo porque la

información sobre éste es mínima, pero no por ello se debe detener el desarrollo, lo que
se hace es avanzar con una manera distinta de enfocar el proyecto; y mientras que más
información va apareciendo, los riesgos van disminuyendo. Cuanto con más antelación
se vayan reconociendo los riesgos en el proyecto, más exactas serán las planificaciones
y expectativas de los resultados. Durante toda la ejecución del proyecto, la gestión de
riesgos examina los cambios que puedan aparecer para generar respuestas apropiadas, y
revisa si hay riesgos existentes que ya no sean aceptables; también ayuda a la obtención
de fechas y costos más precisos para el proyecto. Siempre que se tengan soluciones a
los riesgos, éstas son revisadas y guardadas para futuros usos y posibles mejorías.

72
La gestión de riesgos siempre es una herramienta para la gestión de proyectos y mejora
los valores de otros procesos de gestión de proyectos. La gestión de riesgos debería
llevarse a cabo en consistencia con otras prácticas y normas organizacionales; en este
contexto, la gestión de riesgos deberá reconocer los desafíos del negocio así como
entornos multiculturales asociados con un entorno global cada vez más creciente, que
incluye proyectos multi-empresariales, clientes, proveedores y trabajadores en
diferentes partes del mundo.

Si se dan cambios en el plan de gestión del proyecto como resultado del proceso de
gestión de riesgos, puede necesitar de decisiones a un nivel de administración para
reasignar personal, modificar o establecer presupuestos, realizar acuerdos con otras
entidades, interactuar con reguladores, y obedecer normas de responsabilidad y leyes.
La gestión de riesgos deberá trabajar bajo cumplimento de estos requerimientos internos
y externos.

Es importante destacar la presencia de valores como la responsabilidad, honestidad,

ética, realismo, profesionalidad y trato imparcial con otros para lograr una gestión de
riesgos con éxito. La gestión de riesgos se beneficia de intensas comunicaciones y
consultas con los patrocinadores, lo cual permite un acuerdo entre patrocinadores que la
gestión de riesgos en general sea llevada a cabo de manera objetiva y realista, y no sea
sujeta a otras influencias indecentes como políticas, de interés, entre otras.

Todos de proyectos deberían implementar la gestión de riesgos a lo largo de su

desarrollo, pero el nivel de detalle, la sofisticación de las herramientas, el tiempo
requerido y los recursos implicados deben ser proporcionales a las características del
proyecto en gestión y de los resultados finales. Si un proyecto otorga resultados a un
cliente importante, teóricamente requerirá de más recursos, tiempo y atención a la
gestión de riesgos, que uno de menor envergadura, con menor duración, o interno que se
pueda llevar a cabo paralelamente a otros y con parámetros flexibles.

5.1.1 Factores de éxito críticos para la gestión de riesgos:

• Reconocimiento del valor de la gestión de riesgos: La gestión de riesgos del

proyecto debe ser reconocida como una disciplina valuable que brinda un
potencial retorno positivo o inversión para la administración organizacional, los
proveedores, la administración del proyecto y el equipo de trabajadores.
• Compromiso individual/responsabilidad: Tanto los participantes del proyecto
como los patrocinadores deberán acepar la responsabilidad de hacerse cargo de
actividades relacionadas con el riesgo tanto sea necesario, es responsabilidad de
todos.
• Comunicación honesta y abierta: Todos deberán involucrarse en la gestión de
riesgos. Cualquier acción o actitudes que dificulten las comunicaciones sobre
riesgos del proyecto, reducirá la efectividad de la gestión de riesgos en términos
de anticipación a los problemas y toma de decisiones efectiva.
• Compromiso organizacional: Se puede establecer únicamente si la gestión de
riesgos se concuerda con los objetivos y valores de la organización. La gestión
de riesgos podrá requerir de un mayor nivel de soporte directivo que otras
disciplinas de la administración del proyecto, porque hacerse cargo de algunos
de los riesgos requerirá la aprobación de otros a niveles por debajo del
administrador del proyecto.

73
 • Esfuerzo de riesgo a medida del proyecto: Las actividades de la gestión de
riesgos deberán ser las adecuadas respecto al valor del proyecto para la
organización y con los niveles de riesgos, sus dimensiones, y otras restricciones
organizacionales. En particular, el coste de la gestión de riesgos deberá ser
apropiado con el valor potencial del proyecto y la organización.
• Integración con la administración del proyecto: La gestión de riesgos no existe
por sí sola, aislada de otros procesos de la administración del proyecto. Una
gestión de riesgos exitosa requerirá de una ejecución correcta de otros procesos
de la administración del proyecto.

5.2 PRINCIPIOS Y CONCEPTOS:

Un riesgo es una condición o evento potencial que de ocurrir puede tener efectos
positivos o negativos en los objetivos del proyecto; esta definición incluye dos
dimensiones clave del riesgo, que son el efecto en los objetivos del proyecto y la
incertidumbre. Cuando se valora la importancia de un riesgo, se debe considerar ambas
dimensiones, en las que la incertidumbre será referida en términos de probabilidad, y el
efecto, en términos de impacto o consecuencia.

La definición de riesgo incluye eventos aislados que son inciertos pero pueden
describirse claramente, así como condiciones más generales, que son menos específicos
pero que también pueden dar riesgo a la incertidumbre. A los riesgos de efectos
positivos se les denominan oportunidades, mientras que a los de efectos negativos,
amenazas. Es importante el llevar ambos conjuntamente dentro de un mismo proceso de
gestión de riesgos ya que permite ganancias en la asociación y eficiencia, como tratar a
ambos con el mismo análisis y coordinar respuestas a los dos si se solapan o se pueden
reforzar el uno al otro.

Al hablar de riesgos, es importante hacer una diferenciación entre un riesgo y una

característica asociada al riesgo, tal como causa y efecto. La causa es el evento o
situación que existe o podrá existir y puede conllevar a riesgos, en cambio el efecto
viene a ser una condición o serie de condiciones que pueden afectar a los objetivos del
proyecto, en caso el riesgo asociado ocurriese. Dado el caso que un riesgo ocurriese,
pasaría a ser un problema, y una oportunidad sería un beneficio, los cuales conllevan a
acciones fuera del alcance del proceso de gestión de riesgos. La cadena de causa-riesgo-
efecto se puede utilizar para la documentación, para asegurar que cada uno de estos es
propiamente descrito.

5.2.1 Riesgos individuales y riesgo global del proyecto:

Los riesgos individuales son eventos o condiciones puntuales que pueden repercutir en
algún o algunos objetivos, elementos o tareas del proyecto, de manera positiva o
negativa. La gestión de riesgos continua se centra en estos riesgos individuales, para
entender de qué manera aplicar esfuerzos y recursos para resaltar las opciones de éxito.

El riesgo global del proyecto representa el efecto que puede causar alguna
incertidumbre en todo el proyecto en conjunto, y por ello es diferente a una simple suma
de riesgos individuales, ya que no afecta a un grupo de elementos del proyecto sino a su
totalidad. Representa la exposición de los patrocinadores a las implicaciones de las

74
variaciones en la salida del proyecto. Es un componente importante en la toma de
decisiones, en la administración de programas y portafolios, y en el gobierno del
proyecto en donde las inversiones se permiten o cancelan y se fijan prioridades. A tan
altos niveles es necesario fijar objetivos realistas para el costo y la duración del
proyecto, establecer los niveles de reserva para contingencia necesarios para proteger a
los patrocinadores, fijar prioridades adecuadas, y verificar si el riesgo global aumenta o
decrece a medida que se van aplicando los avances establecidos.

5.2.2 Posturas del patrocinador ante el riesgo:

Las posturas ante el riesgo de los patrocinadores determinan la extensión hasta la cual
un riesgo individual o global tiene importancia; dichas posturas son influenciadas por
un amplio rango de factores, los cuales incluyen la escala del proyecto dentro del rango
de actividades globales de los patrocinadores, la fortaleza de los acuerdos públicos
hechos respecto el desempeño del proyecto, y la sensibilidad de los patrocinadores
sobre temas como impactos medioambientales, relaciones industriales, y otros factores.
Las posturas ante el riesgo de los patrocinadores suelen resultar en deseos de una mayor
certeza en la salida de los proyectos, y pueden expresar preferencia por algún objetivo
sobre otro. La manera en la que el riesgo es considerado también es fuertemente
influenciada por la cultura de la organización, y en función de qué tan abiertos están o
no a diferentes posibilidades, esto puede influenciar a la gestión de riesgos.

El entendimiento de las actitudes del patrocinador hacia un riesgo es un factor clave

para la planificación de la gestión de riesgos, para optimizar tanto la satisfacción del
patrocinador como el éxito del proyecto. Estas actitudes se deben identificar y
administrar de manera conjunta y sin apuros, a lo largo de la gestión de riesgos. Pueden
diferir entre proyectos para el mismo patrocinador y usualmente difieren de un grupo de
patrocinadores a otro; de hecho, un único patrocinador puede adoptar diferentes
actitudes ante el riesgo en diferentes etapas del mismo proyecto.

5.2.3 Proceso iterativo:

A lo largo del desarrollo de un proyecto, las condiciones en las que éste progresa no
siempre permanecen igual y van cambiando, por lo que algunos riesgos ocurrirán y
otros no, aparecerán nuevos riesgos, y sus características pueden ir variando. La
cantidad de información que se tiene sobre los riesgos suele aumentar a medida que
pasa el tiempo. Dadas estas razones, los procesos de la gestión de riesgos en un
proyecto deben ir repitiéndose, y los planes correspondientes, ser elaborados
progresivamente durante todo el proyecto.

Una gestión de riesgos efectiva se asegura revisando periódicamente la identificación y

análisis de los riesgos, monitorizando el progreso en las acciones de respuesta a un
riesgo, y ajustando debidamente los planes de acción según los cambios, pero en caso
de cambiar a un nivel mayor, se deberá revisar la planificación de la gestión de riesgos.
La evaluación y el desarrollo de un plan para los riesgos es únicamente el comienzo, en
el que la frecuencia con la que hagan revisiones y actualizaciones dependerá de las
necesidades y características en las que se desarrolle el proyecto.

5.2.4 Comunicación:

75
La comunicación es un factor vital para el éxito de la gestión de riesgos, dado que su
funcionamiento se basa en la entrada de información vital sobre el proyecto, así como
en la comunicación con los patrocinadores para asegurar que no se esté pasando nada
por alto y que cada riesgo sea tratado de manera realista. Un claro entendimiento de los
procesos de gestión de riesgos es vital para que todo el personal implicado en ello se
comprometa y otorgue credibilidad a lo que se hace, y para ello es requerida una
comunicación honesta y efectiva entre los encargados de la gestión de riesgos con el
resto del personal de la organización, y los patrocinadores. Al comunicar los resultados
del proyecto a los patrocinadores, éstos deben ser orientados para la satisfacción de las
necesidades del patrocinador, y se debe reflejar dentro de la estrategia de
comunicaciones del proyecto con cada responsabilidad y rol del patrocinador en la
gestión de riesgos.

5.2.5 Responsabilidad para la gestión de riesgos:

Los riesgos son problemas potenciales que pueden afectar los objetivos del proyecto, y
cualquiera que tenga interés en alcanzar esos objetivos deberá tomar parte en la gestión
de riesgos, por lo que se suele decir que es “tarea de todos”. Es importante que la
gestión de proyectos no sea asignada únicamente a unos pocos expertos en la materia.
Siempre se debe establecer y comunicar claramente cuál será el rol de cada persona para
con la gestión de riesgos, ya que si bien todos deben asumir responsabilidades en ello,
dependiendo de su cargo y su relación con los objetivos, se pueden tener más, menos o
diferentes responsabilidades. Se debe asegurar que cada persona tenga una
responsabilidad específica asignada dentro de un proceso para riesgos, así como las
acciones necesarias para implementar las respuestas pactadas. Siempre que se lleve a
cabo una acción contra un riesgo, ésta debe ser documentada para posibles usos futuros.

5.2.6 Rol del administrador del proyecto en la gestión de riesgos:

A diferencia del resto del personal que trabaja en el proyecto, el administrador es la

persona responsable sobre los demás, tanto por el continuo desarrollo del proyecto y
alcance de los objetivos como por la correcta gestión de riesgos, y su rol incluye:
• Fomentar el apoyo administrativo de mayor nivel para las actividades de gestión
de riesgos.
• Determinar niveles aceptables de riesgo para el proyecto, conjuntamente con los
patrocinadores.
• Desarrollar y aprobar el plan de gestión de riesgos.
• Promover el proceso de gestión de riesgos para el proyecto.
• Facilitar comunicaciones abiertas y honestas sobre el riesgo entre el personal
encargado del proyecto, con los administradores y patrocinadores.
• Ser partícipe en todos los aspectos del proceso de gestión de riesgos.
• Aprobar respuestas a riesgos y acciones asociadas previas a la implementación.
• Aplicar los fondos de contingencia del proyecto para sobrellevar riesgos
identificados que llegan a ocurrir durante el desarrollo del proyecto.
• Supervisar la gestión de riesgos de los subcontratados y proveedores.
• Reportar regularmente el estado de riesgos a los patrocinadores clave,
recomendando decisiones estratégicas y otras acciones para mantener niveles de
riesgo aceptables.
• Pasar los riesgos en aumento a la administración de mayor nivel en donde sea
apropiado.
76
 • Monitorear la efectividad y eficiencia del proceso de gestión de riesgos.
• Supervisar las respuestas a los riesgos para certificar su efectividad y
documentar los hechos.

5.3 INTRODUCCIÓN A LOS PROCESOS DE GESTIÓN DE RIESGOS:

Un proyecto está siempre cargado de incertidumbres, dado que tiene siempre varios
aspectos que están basados en limitaciones y suposiciones. La administración de
proyectos viene a ser como una forma de controlar estas incertidumbres gracias al uso
de diversas técnicas estructuradas y disciplinadas, en el que cada elemento desempeña
un papel en la definición y control de incertidumbres.

Si se desea que la gestión de riesgos sea completamente efectiva en la administración de

un proyecto, no se le puede tomar como una actividad auxiliar o extra. Dado que varios
elementos de la administración del proyecto llevar incertidumbres consigo, la interfaz
entre la gestión de riesgos y los otros procesos de la administración del proyecto deben
ser aclarados. Las salidas de la gestión de riesgos son tomadas en cuenta por varios
procesos de administración, y pueden influenciar:
• La estimación de requerimientos de recursos, costos y duraciones
• La evaluación del impacto de los cambios de alcance propuestos
• La planificación o replanteamiento de la siguiente estrategia del proyecto
• La repartición de recursos a las tareas
• El reporte del progreso a los patrocinadores

Ninguna de estas acciones de pueden llevar a cabo sin una clara revisión de los riesgos
en cuestión determinados por el proceso de gestión de riesgos, la cual incrementa con
sus resultados la efectividad de la administración del proyecto. Además que una gestión
de riesgos efectiva necesita retroalimentación de otros procesos administrativos como el
WBS, estimaciones, el itinerario del proyecto, lista de suposiciones, etc.

5.3.1 Procesos de gestión de riesgos:

De acuerdo a la definición de un riesgo, éstos son los que afectan a los objetivos, y por
ello es primordial que al comienzo del proceso de gestión de riesgos se definan los
objetivos. Es también importante aclarar que diferentes proyectos son expuestos a
diferentes grados de riesgo, por lo que cada paso en el proceso de gestión de riesgos
debe escalarse de acuerdo a los niveles variantes de riesgo. Los elementos escalables del
proceso incluyen:
• Recursos disponibles
• Metodologías y procesos utilizados
• Herramientas y técnicas utilizadas
• Infraestructura disponible
• Revisión y actualización de la frecuencia
• Reporte de requerimientos

Antes de proceder a implementar la gestión de riesgos, es muy importante comprender

los límites que los patrocinadores ponen como niveles aceptables de riesgos, así como
un marco contra el que se puedan evaluar los riesgos identificados.

77
En consecuencia, la gestión de riesgos comienza siempre con un paso de iniciación, en
el cual se asegura un acuerdo tanto entre el personal del proyecto como con los
patrocinadores, de que el enfoque, parámetros, y otros detalles que se usarán para la
gestión de riesgos. Las principales acciones para proporcionar la adaptación requerida
son las siguientes:
• Definir los objetivos sobre los cuales se identificarán los riesgos
• Definir cómo se escalaran los elementos del proceso de gestión de riesgos para
este proyecto
• Definir las tolerancias y límites de los riesgos, y el marco de evaluación

Las salidas de estos pasos iniciales se deberán documentar, comunicar, y ser revisadas
por los patrocinadores para asegurar el entendimiento común del alcance objetivos del
proceso de gestión de riesgos. Dicho documento deberá ser aprobado formalmente a un
nivel superior.

Una vez resueltos los pasos iniciales, se procede a identificar riesgos, siempre haciendo
distinción de los verdaderos riesgos de los que lo aparentan, como las causas, los
efectos, problemas, etc. Cada riesgo se puede identificar utilizando una o varias técnicas
diferentes, en función de las necesidades del proyecto. Se deberá siempre de exponer y
documentar todos los riesgos conocidos, sabiendo que algunos son desconocidos y otros
aparecerán más adelante. Debido a que la naturaleza de los riesgos es emergente, el
proceso de identificación de riesgos deberá ser iterativo, y la búsqueda de riesgos debe
ser conjuntando la perspectiva de todos los patrocinadores, que suelen ser diferentes.

El historial almacenado de otros riesgos anteriores y otros proyectos se deberá revisar

para ayudar a buscar más riesgos. Idealmente, cada riesgo identificado debe ser
asignado a un responsable o Risk Owner, el cual tendrá el deber de administrar el riesgo
a lo largo del resto del proceso de gestión de riesgos.

Seguidamente de la identificación de riesgos, se debe determinar la importancia de cada

uno y priorizar, evaluar el nivel de riesgo de todo el proyecto y determinar respuestas
apropiadas. Los riesgos se pueden evaluar con técnicas cualitativas para tratar riesgos
individuales, con técnicas cuantitativas para considerar el efecto general del riesgo en el
proyecto, o con ambos. Cada técnica requerirá diferentes tipos de datos, pero siendo uno
u otro el utilizado, se deberá realizar un enfoque integral.

Las técnicas cualitativas sirven para comprender mejor los riesgos individualmente,
tomando diferentes aspectos técnicos en cuenta para lograr este objetivo, dado que
comprender y priorizar riesgos es un prerrequisito esencial para la administración de
éstos. Los resultados obtenidos con las técnicas cualitativas se deberán documentar,
comunicar a los patrocinadores y formar las bases para generar respuestas.

Las técnicas cuantitativas en contraparte, proporcionan una visión general de la

combinación de los efectos de los riesgos identificados en el proyecto. Estas técnicas
consideran efectos probabilísticos o a nivel de todo el proyecto, y su resultado es una
indicación del nivel de riesgo que afronta el proyecto como conjunto. El desarrollo de
respuestas a dichos riesgos deberá tener en cuenta los resultados de dichas técnicas, y
ser documentado y comunicado para informar de acciones posteriores. A diferencia de

78
las técnicas cualitativas, las cuantitativas no son un requisito para una buena gestión de
riesgos.

Una vez detectados y priorizados los riesgos individuales y entendidos los riesgos
globales, se debe proceder a generar las respectivas respuestas iterativamente hasta
encontrar el punto óptimo. Es común que exista más de una respuesta posible tanto a las
amenazas como a las oportunidades por lo que el gestor deberá escoger la más adecuada
basado en las características y prioridades de los respectivos riesgos; en caso exista una
estrategia que trate varios riesgos a la vez, deberá tomarse en cuenta.

Posteriormente el gestor se responsabilizará de poner en marcha los procedimientos

para llevar la respuesta a cabo y repartir la responsabilidad de los procedimientos al
personal. El desarrollo de respuestas deberá ser supervisado y evaluado por si
apareciesen riesgos secundarios u otras complicaciones. Es importante resaltar que más
que aplacar los riesgos individuales, las respuestas deberán siempre apuntar a los
riesgos globales, así como ser documentadas y comunicadas a los patrocinadores.

El proceso de gestión de riesgos está compuesto de la siguiente manera:

• Planificación de la gestión de riesgos: Define el alcance y objetivos del proceso
de gestión de riesgos, y asegura que el proceso de riesgo es integrado totalmente
en la administración del proyecto.
• Identificación de riesgos: Identifica tantos a riesgos conocibles como factibles.
• Análisis cualitativo de riesgos: Evalúa las características clave de los riesgos
individuales permitiendo priorizarlos para posteriores acciones.
• Análisis cuantitativo de riesgos: Evalúa los efectos combinados de riesgos en el
global del proyecto.
• Planificación de respuestas: Determina las estrategias y acciones de respuestas
apropiadas para cada riesgo individual y global, y los integra a un plan de
administración consolidado.
• Monitoreo y control de riesgos: Implementa acciones concertadas, revisa
cambios en exposiciones a riesgos, identifica si se requieren acciones
adicionales, y evalúa la efectividad del proceso de gestión de riesgos.

5.4 PLANIFICACIÓN DE LA GESTIÓN DE RIESGOS:

La idea del proceso de gestión de riesgos es la de desarrollar una estrategia global para
gestionar riesgos en el proyecto, decidir cómo se ejecutarán los procesos implicados, e
integrarse a las actividades de la administración del proyecto. Una gestión de riesgos
efectiva requiere de un plan, en el que se describa de qué manera se llevarán a cabo los
procesos de gestión de riesgos y cómo se relacionarán con otros procesos de
administración del proyecto.

Para garantizar un mejor provecho, la planificación de la gestión de riesgos se debe

realizar en el comienzo de la planificación general del proyecto, así como integrar sus
actividades en el plan de administración del proyecto. Posteriormente se modificará el
plan de gestión de riesgos tomando en cuenta la progresión del proyecto y a los
patrocinadores.

79
A pesar de que la gestión de riesgos forme parte de la administración del proyecto, se le
deben dedicar aparte costos, recursos y tiempo para poder seguir y controlar mejor los
gastos a lo largo del proyecto. El plan de gestión de riesgos deberá describir cómo los
recursos asignados son asignados y gestionados, también definirá los métodos de
monitoreo para asegurar que los gastos son seguidos apropiadamente, así como las
condiciones bajo las que se modificaría el presupuesto de la gestión de riesgos.

Ya se mencionó así como la administración del proyecto, la gestión de riesgos es un

proceso recursivo en el que se debe definir tanto la frecuencia de repetición como las
condiciones específicas bajo las que se deberían iniciar las acciones correspondientes,
que también se integrarán al plan administrativo del proyecto. Existen dos categorías de
criterios de éxito para gestión de riesgos que son aquellas para el éxito del proyecto en
general y aquellas otras para el éxito de la gestión de riesgos:
• Criterios relativos al proyecto: Para evaluar el éxito de la gestión de riesgos, los
patrocinadores deben concordar en un nivel de resultados aceptable para los
criterios relativos al proyecto, como el costo, tiempo, y alcance. Para asegurar la
concordancia entre patrocinadores, el plan de gestión de riesgos debe presentar
estos objetivos con referencia a los documentos de definición del proyecto. Para
poder orientar la gestión de riesgos y priorizar los riesgos, los patrocinadores
deben antes priorizar los objetivos del proyecto.
• Criterios relativos al proceso: El éxito en gestión de riesgos depende de varios
factores, como el nivel propio de incertidumbre que tenga el proyecto. Si
comparamos un proyecto de fabricación de un producto conocido con el de una
investigación científica, esta última suele tener muchos imprevistos más que van
apareciendo a lo largo de su desarrollo, por lo que al finalizar, si los resultados
escapan del margen previsto inicialmente, pero aceptables, se considerará
igualmente un proyecto exitoso.

Los niveles de riesgos aceptables estarán en función de las actitudes de los

patrocinadores claves hacia los riesgos, en el que dicha actitud tanto por parte de la
empresa como de los patrocinadores puede ser influenciada por diversos factores que
deberán identificarse. Entre estos factores destacan la tolerancia inherente a la
incertidumbre, y su importancia relativa para alcanzar o no los objetivos. Una vez
evaluados estos aspectos se deben establecer límites y niveles de importancia al aplicar
el proceso de gestión de riesgos al proyecto. A medida que el proyecto vaya
progresando se debe mantener comunicación con los patrocinadores para estar al tanto
de nuevos posibles cambios en sus posturas respecto a los riesgos y que sean tomados
en cuenta para adaptar la gestión de éstos.

Es importante que toda la terminología y datos importantes de las herramientas en uso

sean conocidos por el personal, y definidos en concordancia con los objetivos y las
posturas adoptadas; términos tales como “probabilidad mediana” deben de ser
objetivamente especificados en los documentos de gestión para evitar problemas. La
gestión de riesgos deberá establecer el tipo y nivel de detalle de riesgo a tratar, y otorgar
un patrón del registro de riesgos que se usará para documentar información relativa a
riesgos. Deberá también indicar la intensidad del esfuerzo y la frecuencia con la que se
repetirán los procesos de gestión de riesgos, que están en función de las características
del proyecto y de los objetivos de la gestión de riesgos.

80
Es necesario dar a conocer al personal y patrocinadores cuándo y dónde tendrán que
participar, los criterios para determinar si un proceso fue exitoso, su nivel de autoridad,
y qué acciones realizar aparte de sus responsabilidades para asegurar la correcta y
efectiva ejecución de los procesos de gestión de riesgos. Todos estos datos mencionados
previamente deben de ser indicados en el plan de gestión de riesgos.

Las comunicaciones relativas a riesgos ocurren en dos niveles, que son entre miembros
del proyecto, y entre el equipo del proyecto y los patrocinadores. Los fundamentos para
cada una de estas comunicaciones se definen también en el plan de gestión de riesgos,
en donde para el caso de la comunicación entre miembros del proyecto se describe la
frecuencia y alcance de las reuniones y reportes para llevar a cabo los procesos de
gestión de riesgos, así como el contenido de las mismas. Para el caso de la
comunicación con los patrocinadores, el plan pone sus expectativas como la estructura,
contenido, y frecuencia de envío de documentos rutinarios, así como lo que se mandaría
en caso de cambios o eventualidades, y también los detalles de la información requerida
a solicitar a los patrocinadores.

5.4.1 Factores críticos para el éxito del proceso de gestión de riesgos:

Los principales criterios para un plan de gestión de riesgos válido son la aceptación de
los patrocinadores, la uniformización con las limitaciones internas y externas en el
proyecto, el balance entre costo o esfuerzo y beneficio, y la integridad con respecto a las
necesidades del proceso de gestión de riesgos. Los factores críticos para el proceso de
gestión de riesgos son los siguientes:
• Identificar y dirigir los límites hacia una gestión de riesgos exitosa: Los
patrocinadores y administradores del proyecto sólo apoyarán los recursos para la
gestión de riesgos si reconocen y aceptan los beneficios de gestionar los riesgos
y el valor añadido de dirigirlos como habilidad en vez de un componente pasivo
de la gestión del proyecto. El administrador del proyecto deberá asegurarse que
se defina válidamente los objetivos del proyecto y un enfoque del entorno del
proyecto a alto nivel, para la actividad de la gestión de riesgos. La disponibilidad
de unas o todas de las siguientes facilidades contribuyen al éxito de la gestión de
riesgos: patrones estándar, categorías de riesgos predefinidas, metodologías de
gestión de riesgos establecidas con datos de qué datos sobre los riesgos se
necesitan para tomar decisiones, y la definición de conceptos, términos y
responsabilidades. Todo lo mencionado otorga un grado de experiencia que hace
que la gestión de riesgos tome menos tiempo de lo que le podría tomar a una
organización con pocas o sin experiencias previas. Las actividades de la gestión
de riesgos deberán ser incluidas en el WBS del proyecto y en los documentos de
itinerario, presupuesto, y asignación de tareas, de manera que facilite a la
administración del proyecto de emitir su valor.
• Involucrar a los patrocinadores del proyecto en la gestión de riesgos: La
implicación de los patrocinadores en el proyecto es necesaria para aportar su
experiencia y habilidades, así como para asegurar su compromiso y
entendimiento de todo el proceso. El suministro de recursos especificados para
la gestión de riesgos deberá ser aprobado por la administración de manera que se
puedan llevar a cabo las actividades de gestión de riesgos para alcanzar los
objetivos. La administración deberá estar al tanto de las necesidades de recursos
de la gestión de riesgos así como de los riesgos que puedan surgir por limitar la
cantidad de recursos a suministrar. Siempre que surjan desacuerdos entre

81
 patrocinadores en las tolerancias a los riesgos y medidas de evaluación, se
deberán tratar y solucionar.
• Cumplir con los objetivos, políticas y prácticas de la organización: La viabilidad
de la planificación de gestión de riesgos depende de las características de la
organización que lo lleve a cabo, dado que las reglas y pautas definidas en el
plan de gestión de riesgos deberán ser compatibles con la cultura de la
organización, la capacidad de su personal, su infraestructura, valores, y
objetivos. En el plan de gestión de riesgos se deberá tomar en cuenta los
procedimientos relevantes y otros factores organizacionales aplicables.

5.4.2 Técnicas y herramientas para el proceso de gestión de riesgos:

• Sesiones de planificación: Son recomendadas para lograr un entendimiento

común del enfoque hacia los riesgos entre patrocinadores, y de las técnicas a
utilizar. La elaboración del plan de gestión de riesgos sirve para hacer que el
equipo trabaje conjuntamente ya que se utilizará un enfoque grupal de consultas
similar en las siguientes fases del proceso de gestión de riesgos. Los
participantes deberán incluir al administrador del proyecto, los miembros de
equipo del proyecto, los patrocinadores, otros miembros de la organización
relacionados a los riesgos, y expertos en el tema. A este punto todas las
responsabilidades, técnicas, plantillas, definiciones, itinerarios y presupuestos
para gestión de riesgos deben ser asignados y aceptados. Las especificaciones de
las herramientas a utilizar en los siguientes procesos deben incluir todos los
parámetros y demás necesario para asegurar su aplicabilidad. Todo ello se
deberá documentar en el plan de gestión de riesgos, que formalmente aprobado
pasará a ser el principal entregable del proceso de gestión de riesgos.
• Plantillas: Para que resulten beneficiosas las experiencias y buenas prácticas
existentes, la planificación de gestión de riesgos debe tomar en cuenta las
plantillas para productos de trabajo, como los reportes de estado de riesgo,
estructuras de subdivisión de riesgos, o el registro de riesgo. Se deberá decidir
qué plantillas son relevantes para el proyecto, y consiguientemente adaptadas e
incluidas en el plan de gestión de riesgos.

5.4.3 Documentando los resultados del proceso de gestión de riesgos:

El plan de gestión de riesgos sirve para proporcionar una visión común a los
patrocinadores de cómo se tratarán las actividades relacionadas a riesgos, a qué
acuerdos se llegó, y una descripción de las responsabilidades de los patrocinadores en
dichas actividades. A continuación se muestra una tabla con las áreas claves de enfoque:

Gente Herramientas Negocios

Actitudes Caja de herramientas Limitaciones
Roles, responsabilidades, Parámetros Cantidad de detalles y
autoridad esfuerzo
Comunicaciones Definiciones
Tabla 9: Áreas clave de enfoque para la gestión de riesgos

Dependiendo del tamaño y complejidad del proyecto, algunos o todos de los siguientes
elementos se presentarán en el plan de gestión de riesgos:
• Introducción

82
 • Descripción del proyecto
• Metodología de gestión de riesgos
• Organización de gestión de riesgos
• Roles, responsabilidades y autoridades
• Tolerancias al riesgo de los patrocinadores
• Criterios para el éxito
• Herramientas de gestión de riesgos y pautas para su uso
• Límites y definiciones correspondientes
• Plantillas
• Plan de comunicaciones
• Estrategias
• Estructura de subdivisión de riesgos

5.5 IDENTIFICACIÓN DE RIESGOS:

Un riesgo tiene que ser primero identificado antes de ser tratado, por lo que al
finalizarse la planificación, el primer paso del proceso iterativo de gestión de riesgos es
identificar todos los riesgos posibles hacia los objetivos del proyecto, aunque es
imposible poder detectarlos todos. El nivel de exposición al riesgo varía en el tiempo
como resultado de decisiones y acciones tomadas previamente en el proyecto y cambios
externos impuestos.

La idea de la identificación de riesgos es de detectar la mayor cantidad posible de éstos

y de manera iterativa dado que siempre existe la posibilidad de riesgos no detectados o
emergentes. Al ser detectado un riesgo, se deben identificar posibles respuestas
inmediatamente, las cuales se grabarán en el proceso de identificación de riesgos y serán
considerados para tomarse en acción, de ser adecuados. Si las respuestas no son
inmediatamente implementadas, esto se deberá considerar en el proceso de planificación
de respuestas al riesgo.

5.5.1 Factores críticos de éxito para el proceso de identificación de riesgos:

Las prácticas descritas a continuación maximizan el valor y la efectividad del proceso

de identificación de riesgos y aumenta la posibilidad de identificar riesgos:
• Identificación anticipada: La identificación de riesgos se debe realizar lo antes
posible en el ciclo de vida del proyecto, reconociendo que la incertidumbre es
elevada al principio del proyecto por lo que habrá menos información
disponible. La identificación anticipada permite realizar decisiones clave para
tomar más en cuenta a los riesgos y puede resultar en cambios en la estrategia
del proyecto. Maximiza también el tiempo disponible para desarrollar e
implementar las respuestas, que mejoran la eficiencia dado que las respuestas
anticipadas cuestan menos que las tardías.
• Identificación iterativa: Dado que no todos los riesgos se pueden identificar en
un punto del proyecto, es necesario que la identificación sea iterativa. Esta
recursividad deberá tener una frecuencia determinada durante la fase de
planificación. La identificación se deberá repetir también en puntos clave del
proyecto, o cuando quiera que haya cambios significativos en el proyecto o su
entorno.

83
 • Identificación emergente: Además de invocar el proceso de identificación de
riesgos, la gestión de riesgos debe permitir identificar riesgos en cualquier
momento, no necesariamente limitados a eventos en particular o revisiones
continuas.
• Identificación global: Un mayor rango de fuentes de riesgo debe considerarse
para asegurar que se ha identificado tantas incertidumbres que puedan afectar los
objetivos como posible.
• Identificación explícita de oportunidades: El proceso de identificación de riesgos
debe asegurar que las oportunidades sean debidamente consideradas.
• Perspectivas múltiples: El proceso de identificación de riesgos debe nutrirse de
un mayor rango de patrocinadores para asegurar que todas las perspectivas sean
representadas y consideradas. Limitar la identificación de riesgos al personal
directo del proyecto es poco probable que se expongan todos los riesgos
conocidos.
• Riesgos relacionados a objetivos: Cada riesgo identificado se debe relacionar al
menos a un objetivo del proyecto (tiempo, costo, calidad, alcance, etc.), ya que
la definición de riesgo está relacionada con su influencia ya sea positiva o
negativa en algún objetivo. La consideración de cada objetivo en el proceso de
identificación de riesgos ayudará a identificarlos, nada que algunos riesgos
puedan afectar a más de un objetivo.
• Declaración completa de riesgos: Los riesgos identificados deben ser descritos
claramente y sin ambigüedades para ser entendidos por todos los responsables.
Frases o palabras como ‘recursos’ o ‘logística’ no comunican la naturaleza del
riesgo. Se requieren descripciones más detalladas que digan la incertidumbre,
sus causas y efectos.
• Propiedad y nivel de detalle: Los riesgos pueden ser identificados en un número
de niveles de detalle. Una descripción genérica o de alto nivel del riesgo puede
dificultar el desarrollo de respuestas y asignación de responsabilidades, mientras
que muchos detalles pueden generar mucha carga de trabajo. Cada riesgo debe
describirse a un nivel de detalle que se pueda asignar a un único responsable.
Provocar condiciones debe ser también identificado en donde sea posible y
apropiado.
• Objetividad: Toda actividad humana está sujeta a prejuicios, especialmente
tratándose de incertidumbres. Ambos prejuicios motivacionales, en donde
alguien intenta enfocar el resultado en una dirección u otra, o prejuicios
cognitivos, en donde los prejuicios ocurren por personal usando su mejor
opinión y aplicando tanteos, puede ocurrir. Esto deberá ser explícitamente
reconocido y tratado en el proceso de identificación de riesgos. Las fuentes de
prejuicios deben ser expuestas siempre que sea posible, y su efecto en el proceso
de riesgo debe de ser administrado proactivamente. La idea es de aminorar la
subjetividad, y permitir la identificación abierta y honesta de todos los riesgos
posibles.

5.5.2 Técnicas y herramientas para el proceso de identificación de riesgos:

• Revisión histórica: Las revisiones históricas se basan en lo ocurrido en el

pasado, ya sea en el proyecto en cuestión u otros comparables. Su enfoque reside
en la selección cuidadosa de situaciones similares a las del proyecto, y un
filtrado de datos para asegurar que sólo los riesgos previos relevantes son
considerados. En cada caso, los riesgos identificados en la situación histórica

84
 escogida debe considerarse, preguntando si dichos riesgos o similares pueden
aparecer en el proyecto.
• Evaluaciones actuales: Las evaluaciones actuales se basan en consideraciones
detalladas del proyecto actual, analizando sus características contra marcos y
modelos dados para exponer áreas de incertidumbre. A diferencia de la revisión
histórica, técnicas de evaluaciones actuales no se basan en referencias ajenas al
proyecto, sino únicamente en revisiones del proyecto.
• Técnicas de creatividad: Un amplio rango de técnicas de creatividad pueden
usarse para identificar riesgos, que fomentan a los patrocinadores a usar su
imaginación para encontrar riesgos que puedan afectar al proyecto. Los
resultados o la efectividad de estas técnicas dependen en la habilidad de los
participantes de pensar creativamente, y su éxito se realza por le uso de un
conocedor experto. Dichas técnicas pueden utilizarse por sí solas o en grupos, y
emplear niveles de estructura variantes.

Cada técnica de las mencionadas previamente tiene puntos fuertes y débiles, y no se

puede esperar que una técnica sola revele todos los riesgos. En consecuencia, el proceso
de identificación de riesgos para un proyecto debe usar una combinación de técnicas,
talvez con una de cada categoría. El uso de una estructura de subdivisión de riesgos que
organiza las categorías de los riesgos potenciales en un proyecto, una lista de apuntes, o
un grupo de listas de categorías genéricas pueden ayudar a asegurar que se han tratado
la mayoría de fuentes de riesgo posibles, mientras se reconoce que ninguna de dichas
herramientas son completas o pueden reemplazar la opinión original.

Cualquiera que haya sido la herramienta escogida, es importante que los riesgos
identificados sean descritos sin ambigüedades para asegurar que el proceso de gestión
de riesgos está enfocado en los riesgos actuales y no distraídos o diluidos por ‘falsos
riesgos’. El uso de descripciones de riesgos estructuradas asegura claridad. El
metalenguaje de riesgos ofrece una manera útil de distinguir un riesgo de sus causas y
efectos, describiendo cada riesgo haciendo uso de afirmaciones en tres partes, de la
manera: ‘Como resultado de la causa, puede ocurrir un riesgo, que conllevaría efectos’.

5.5.3 Documentando los resultados del proceso de identificación de riesgos:

Los resultados del proceso de identificación de riesgos deben ser grabados para tener
toda información revelante disponible para cada riesgo identificado. Su principal
resultado es el registro de riesgos, el cual incluye una descripción debidamente
estructurada del riesgo y el responsable asignado para cada riesgo, y puede incluir
también información de las causas y efectos del riesgo, condiciones que lo generan, y
respuestas preeliminares.

5.6 ANÁLISIS CUALITATIVO DE RIESGOS:

El análisis cualitativo de riesgos calcula y evalúa las características individuales de los

riesgos identificados y prioriza riesgos en función de características acordadas. Calcular
riesgos individuales utilizando el análisis cualitativo de riesgos evalúa la probabilidad
que cada riesgo ocurra y el efecto de cada riesgo individual en los objetivos. Como tal
no trata el riesgo global en los objetivos que puedan ocasionar efectos combinados y sus
posibles interacciones. Un paso en el análisis es categorizar los riesgos de acuerdo a sus

85
fuentes o causas, si varios riesgos surgen de la misma fuente o causa raíz, las respuestas
pueden ser más efectivas cuando se enfocan hacia la fuente.

Identificar efectos comunes de grupos de riesgos permite identificar áreas de exposición

de riesgos mayores, facilitando que las respuestas al riesgo se enfoquen en dichas áreas.
Los métodos del análisis cualitativo de riesgos son aplicados a la lista de riesgos
creados o actualizados por el proceso de identificación de riesgos, para proveer a la
administración con las características de los riesgos que tienen más influencia en
alcanzar objetivos. Los riesgos que son prioritarios positiva o negativamente para el
proyecto serán puntos importantes en el proceso de planificación de respuestas al riesgo.
Serán analizados posteriormente, así como en el análisis de riesgos global que se
expone en el proceso de análisis cuantitativo de riesgos.

5.6.1 Factores críticos de éxito para el proceso de análisis cualitativo de riesgos:

La llegada a un acuerdo por parte de los patrocinadores es un criterio fundamental y

tema común. El enfoque acordado es el fundamento de la credibilidad del proyecto, y
por ello las definiciones acordadas permiten recoger información de alta calidad.
Finalmente, con dichas condiciones cumplidas, el proceso se puede ejecutar con
seguridad, lo que contribuye a la credibilidad de los resultados.

• Uso de un enfoque acordado: El proceso se basa en un enfoque acordado de la

evaluación que se aplica en todos los riesgos identificados. Por la naturaleza de
los riesgos, todos éstos deben evaluarse de acuerdo a la probabilidad de
ocurrencia e impacto en objetivos individuales. Otros factores se deben
considerar para determinar la importancia de un riesgo:
o Urgencia (proximidad): Los riesgos que requieran de respuestas a corto
plazo se considerarán más urgentes de solucionar. Los indicadores de
urgencia incluyen el tiempo de solucionar, y la claridad de los síntomas y
avisos de advertencia que puede generar la respuesta.
o Administrabilidad: Algunos riesgos no son administrables y sería un
desperdicio de recursos el intentar manejarlos. El equipo del proyecto
debe examinar esto y dedicarse a:
ƒ Seguir adelante, talvez estableciendo una reserva de contingencia.
ƒ Detener o recalcular el alcance del proyecto, porque estos riesgos
suponen una amenaza inmanejable o una oportunidad que no se
puede perder con altas probabilidades y consecuencias.
ƒ Informar al cliente de los riesgos y pedir una decisión desde su
perspectiva.
o Impacto externo al proyecto: Un riesgo puede aumentar su importancia si
afecta a la organización más allá del proyecto.
• Uso de definiciones acordadas de plazos de riesgos: La evaluación de riesgos
debe basarse en definiciones acordadas de plazos importantes, los cuales deben
ser utilizados consistentemente al evaluar cada riesgo. El uso de definiciones
tipo niveles de probabilidad o nivel de impacto en objetivos, ayuda a tener
evaluaciones más realistas para cada riesgo, y facilita la comunicación de los
resultados a la administración y los patrocinadores.
• Recoger información de alta calidad sobre los riesgos: La recogida de
información de alta calidad es necesaria, dado que ésta no es disponible en
ningún registro histórico y debe recogerse por entrevistas, talleres, y otros

86
 medios estratégicos. Los datos recogidos por personas pueden estar sujetos a
reportes o tendencias intencionales. Cuando esto ocurra, las intencionalidades
deben ser identificadas y removidas, o utilizar una fuente no intencional de
información.
• Análisis cualitativos riesgos iterativamente: El éxito del análisis cualitativo de
riesgos mejora si el proceso se repite en el proyecto. Es imposible saber de
antemano todos los riesgos, por lo que la identificación y posterior análisis
cualitativo debe repetirse periódicamente para riesgos individuales. La
frecuencia de ocurrencia será planeada en el proceso de planificación, pero
puede depender de otros eventos en concreto.

5.6.2 Técnicas y herramientas para el proceso de análisis cualitativo de riesgos:

Las técnicas y herramientas utilizadas para evaluar riesgos individuales identificarán los
riesgos importantes para el éxito del proyecto; este proceso se explica paso a paso a
continuación:
• Selección de características que definan la importancia del riesgo: Las
herramientas de análisis cualitativo de riesgos proveen formas de distinguir
riesgos importantes de otros, los criterios más importantes para lograrlo son
acordados previamente e implementados en las herramientas. Los resultados de
dichas herramientas incluyen una lista de riesgos en orden de prioridad o por
grupos de prioridad. Estas herramientas permiten a la organización o
patrocinadores especificar los niveles o combinación de características que
hacen de un riesgo importante para administrar. Varias herramientas determinan
la importancia de un riesgo combinando la probabilidad de ocurrencia y en
grado de impacto en los objetivos.
• Recoger y analizar datos: La evaluación de riesgos individuales se basa en la
información recogida sobre ellos, por lo tanto las herramientas de recogida y
evaluación de datos requieren soporte y atención de la administración. Es
importante proteger de prejuicios la recolecta de datos, que es importante al
opinar sobre la información.
• Priorizar riesgos por probabilidad de impacto en objetivos específicos: Algunas
herramientas permiten distinguir prioridades de riesgos en términos del objetivo
afectado. Esta capacidad permite priorizar los riesgos de objetivos importantes, y
es muy útil porque es común para los riesgos tener impactos desiguales en
diferentes objetivos.
• Priorizar riesgos por probabilidad de impacto en el global del proyecto: Existen
razones para hacer una medida para la importancia de riesgos específicos de
todo el proyecto en contraste con la importancia a objetivos específicos. Una
razón usual es para facilitar la comunicación entre la administración y los
patrocinadores. Cuando se requiere de una lista de priorización de riesgos
individuales, la organización debe ser explícita en cómo dicha lista es creada.
Generalmente la lista refleja la preferencia de la organización para con los
objetivos. La técnica para crear medidas de prioridad para riesgos globales debe
documentarse en el proceso de planificación de gestión de riesgos.
• Categorizar causas de riesgos: Una apropiada categorización de los riesgos
puede mejorar el análisis de la probabilidad y magnitud de riesgos y respuestas
efectivas. Comprender las relaciones entre riesgos mejora el entendimiento del
riesgo global del proyecto que si los riesgos se considerasen sólo aislados.
Identificar causas comunes en un grupo de riesgos, por ende, revela la magnitud

87
 de un evento de riesgo para un grupo, así como estrategias efectivas para
resolverlos simultáneamente. Algunos riesgos, alternativamente, pueden
relacionarse con otros a través de una cadena de causas, y entender la cadena de
riesgos mejora la comprensión de la implicación del riesgo en el proyecto.
Identificar riesgos que pueden ocurrir simultáneamente o utilizar los mismos
recursos para recuperación puede otorgar una imagen realista de los problemas
de moderación de riesgos utilizando escasos recursos. Combinar los resultados
del análisis cualitativo de riesgos con la estructura de subdivisión de riesgos,
puede revelar grupos de prioridad de riesgos surgiendo de fuentes específicas.
Una combinación de la información de análisis de riesgos con el WBS puede
mostrar qué áreas de proyecto están en mayor riesgo. Evaluar los impactos de
los riesgos de alta prioridad en objetivos puede indicar las actividades a tratar
para reducir la incertidumbre. Todos estos enfoques contribuyen al realismo y
utilidad del análisis cualitativo de riesgos.
• Documentar los resultados del proceso de análisis cualitativo de riesgos: El
proceso de análisis cualitativo de riesgos contribuye a estructurar los riesgos no
diferenciados en categorías de prioridad. A cada riesgo se le asigna una
prioridad, en función del objetivo afectado o del proyecto entero. Esta
información suele guardarse en el registro de riesgos que es fácil para usar y
actualizar. La lista de riesgos priorizados se comunica a los participantes que son
responsables por acciones para mejorar el plan de proyecto. Los de alta prioridad
se separan para análisis exhaustivos y planificación de respuestas, y se sondean
frecuentemente, mientras que los de baja prioridad se dejan en lista de
observación y se revisan menos veces para cambios en sus estados.

5.7 ANÁLISIS CUANTITATIVO DE RIESGOS:

El proceso de análisis cuantitativo de riesgos proporciona una estimación numérica del

efecto global del riesgo en los objetivos del proyecto, basándose en planes e
información vigentes, cuando se consideran los riesgos simultáneamente. Los resultados
de estos análisis se usan para evaluar la posibilidad de éxito de los objetivos y estimar
reservas de contingencia, usualmente de costo y tiempo para los riesgos y las tolerancias
a los riesgos de los patrocinadores.

Se suele aceptar que analizar la incertidumbre en un proyecto con técnicas cuantitativas

como la simulación Monte Carlo otorgan más realismo en la estimación del costo o
itinerario global del proyecto que un enfoque no probabilístico que asume que las
duraciones de las actividades o estimaciones de costos específicos son deterministas.
Sin embargo, el análisis cuantitativo de riesgos no es siempre requerido o apropiado
para todos los proyectos, sobre todo para proyectos pequeños; si un análisis cualitativo
de riesgos otorga la información suficiente para desarrollar respuestas efectivas, será
suficiente. Por lo tanto, en proceso de planificación de gestión de riesgos, los beneficios
del análisis cuantitativo de riesgos deben ser comparados con el esfuerzo requerido para
asegurar que las visiones adicionales y valores justifiquen el esfuerzo adicional.

Los análisis parciales de riesgos, como el cualitativo, no producen medidas contra el

riesgo global al considerarse todos los riesgos simultáneamente. Realizar cálculos del
riesgo global es la misión del análisis cuantitativo de riesgos. Los riesgos específicos
son mejor comprendidos y cuantificados a nivel detallado como el costo específico o

88
nivel de actividad de itinerario. En contraste, los objetivos como alcanzar el presupuesto
o itinerario del proyecto se especifican a un nivel mayor, que suele ser el nivel del
proyecto total. Un análisis global de riesgos, como al utilizar técnicas cuantitativas,
calcular la implicación de todos los riesgos cuantificados en los objetivos. La
implementación del dicho análisis utilizando métodos cuantitativos requiere de:
• Representación completa y precisa de los objetivos a partir de los elementos
individuales del proyecto. Ejemplos de dichas representaciones incluyen la
estimación de costos e itinerario.
• Identificar riesgos en elementos individuales del proyecto como actividades de
itinerario o costos específicos a nivel de detalle que se presten para evaluaciones
específicas de riesgos individuales.
• Incluir riesgos genéricos que tengan un efecto más amplio en elementos
individuales del proyecto.
• Aplicar un método cuantitativo (simulación Monte Carlo, análisis de árbol de
decisiones) que incorpore múltiples riesgos simultáneamente para determinar el
impacto global en el objetivo global del proyecto.

Los resultados del análisis cuantitativo se compararán con el plan de proyecto (de línea
base o actual) para dar a la administración una estimación del riesgo global y responder
a preguntas importantes como:
• ¿Cuál es la probabilidad de alcanzar los objetivos?
• ¿Cuánta reserva de contingencia se requiere para dar a la organización el nivel
de certeza que requiere basado en su tolerancia al riesgo?
• ¿Cuáles son esas partes del proyecto, como los costos específicos o actividades
de itinerario, que contribuye el mayor riesgo cuando todos los riesgos se
consideran simultáneos?
• ¿Qué riesgos individuales contribuyen al mayor riesgo global del proyecto?

Estimar el riesgo global usando métodos cuantitativos ayuda a distinguir aquellos

proyectos en los cuales los riesgos cuantificados amenazan los objetivos más allá de la
tolerancia de los patrocinadores, de esos para los que los objetivos están dentro de las
tolerancias aceptadas aun considerando los riesgos. En el caso de amenazas se deben
preparar respuestas a riesgos con la intención de proteger los objetivos más
trascendentes para los patrocinadores.

Análisis Cualitativo de Riesgos Análisis Cuantitativo de Riesgos

• Trata los riesgos individuales de • Predice posibles resultados del
manera descriptiva proyecto basado en efectos
• Evalúa la probabilidad discreta de combinados de riesgos
ocurrencia e impacto en objetivos si • Usa distribuciones probabilísticas
ocurriese para calcular la probabilidad de
• Prioriza riesgos individuales para riesgo e impacto
posteriores tratamientos • Usa un modelo de proyecto (como
• Añade al registro de riesgos itinerario, estimado de costos)
• Conlleva a análisis cuantitativo de • Usa un método cuantitativo, requiere
riesgos de herramientas especializadas
• Estima la posibilidad de alcanzar
objetivos y la contingencia necesaria
para alcanzar niveles deseados de

89
 comodidad
• Identifica riesgos con efectos
mayores globales en el proyecto
Tabla 10: Comparación análisis cualitativo y cuantitativo

5.7.1 Factores críticos de éxito para el proceso de análisis cuantitativo de riesgos:

Para alcanzar los objetivos del análisis cuantitativo de riesgo con éxito, se depende
expresamente por lo menos, en los factores siguientes:
• Previa identificación de riesgos y análisis cualitativo de riegos: El proceso de
análisis cuantitativo de riegos ocurre después que la identificación de riegos y el
proceso de análisis cualitativo de riesgos finalicen. Hacer referencia a una
priorizada lista de riesgos identificados asegura que el proceso de análisis
cuantitativo de riesgos considerará todos los riesgos significativos al analizar sus
efectos cuantitativamente.
• Modelo de proyecto apropiado: Un modelo apropiado del proyecto debe usarse
como base para el análisis cuantitativo. Los modelos de proyecto utilizados más
habitualmente en el análisis cuantitativo incluyen el itinerario (de tiempos),
estimaciones específicas de costos, árbol de decisiones (para decisiones con
incertidumbres) y otros modelos de proyecto-total. El análisis cuantitativo es
especialmente sensible a la integridad y precisión del modelo de proyecto en
uso.
• Compromiso de recolección de datos de alta calidad sobre riesgos: Los datos de
alta calidad sobre los riesgos suelen no estar disponibles in ninguna base de
datos histórica y se deben recoger por entrevistas, talleres, y otros medios
haciendo uso de opiniones de expertos. La recolección de datos sobre riesgos
requiere recursos y tiempo, así como también de soporte administrativo.
• Datos imparciales: El éxito de recoger datos de análisis sobre riesgos requiere de
la habilidad de reconocer cuando ocurren prejuicios y combatirlos o desarrollar
otras fuentes de datos imparciales. Los prejuicios en los datos sobre riesgos
pueden pasar por diversas razones, pero dos fuentes comunes son prejuicios
cognitivos y motivacionales.
• Riesgos globales derivados de riesgos individuales: El proceso de análisis
cuantitativo se basa en una metodología que deriva correctamente el riesgo
global de riesgos individuales. En el análisis de riesgos de costo e itinerario, por
ejemplo, un método adecuado es la simulación de Monte Carlo. Un árbol de
decisiones es un método importante para hacer decisiones cuando los eventos
futuros no son ciertos, utilizando probabilidad de impacto de todos los riesgos, y
combinando su efecto para derivar una medida global del proyecto como valor o
costo. En cada método, los riesgos se especifican al nivel de tareas detalladas o
costos específicos y se incorporan en el modelo del proyecto para calcular los
efectos en los objetivos como itinerario o costo de todo el proyecto, al combinar
los riesgos.
• Inter-relaciones entre riesgos en el análisis cuantitativo de riesgos: Se debe
prestar atención a la posibilidad que los riesgos individuales puedan estar
relacionados entre si, como en el caso de que varios sean originados por la
misma causa y por ende puedan ocurrir juntos. Dicha posibilidad es a veces
tratada correlacionando los riesgos relacionados, asegurando que suelen ocurrir
juntos durante el análisis. Otra forma de representar los riesgos que ocurren
juntos es la de utilizar la lista de registro de riesgos del riesgo o causa en

90
 cuestión y añadirlo a diversos elementos del proyecto como las actividades de
itinerario o elementos de costos. Si ocurre algún riesgo en particular, todos los
elementos afectados experimentarán juntos el efecto.

5.7.2 Técnicas y herramientas para el proceso de análisis cuantitativo de riesgos:

Las técnicas y herramientas utilizadas adecuadamente para el análisis cuantitativo tienen

diversas características, que son:
• Representación integral del riesgo: El modelo del riesgo permite la
representación de todos o varios de los riesgos que pueden tener impactos en los
objetivos a la vez. Permite también representar las amenazas y oportunidades
hacia los objetivos.
• Cálculo del impacto del riesgo: Los modelos cuantitativos facilitan el correcto
cálculo del efecto de varios riesgos, que son normalmente identificados y
cuantificados a un nivel de detalle por debajo de todo el proyecto, en los
objetivos, los cuales son generalmente descritos al nivel de todo el proyecto.
• Método cuantitativo adecuado para analizar la incertidumbre: Los modelos de
probabilidad usan un método cuantitativo que trata la incertidumbre, los cuales
deben poder manejar la manera en que se representa la incertidumbre, sobre todo
como probabilidad de ocurrencia de un evento o como distribuciones de
probabilidades para un rango de resultados. Un ejemplo de esto es el uso de las
herramientas de simulación Monte Carlo que permiten combinar distribuciones
de probabilidad de costos específicos o duraciones de actividades, muchas de las
cuales son inciertas.
• Herramientas de recolección de datos: Las herramientas para obtener datos en
este proceso incluyen la evaluación de datos históricos y talleres, entrevistas, o
cuestionarios para recoger información cuantificada, por ejemplo, en la
probabilidad de ocurrencia de un riesgo, una distribución de probabilidad de sus
impactos potenciales en costos o tiempo, o las relaciones como la correlación
entre riesgos.
• Presentación efectiva de los resultados del análisis cuantitativo: Los resultados
cuantitativos son suelen estar disponibles en métodos de administración de
proyectos determinados estándares como el itinerado del proyecto o estimado de
costos. Ejemplo de esto es la distribución probabilística de las fechas de
finalización o costos totales y el valor esperado de una decisión de proyecto.
Estos resultados, cuando se consideran todos los riesgos a la vez, incluyen:
o Probabilidad de alcanzar objetivos como acabar en el tiempo y coste
calculados.
o Cantidad de reserva de contingencia en costo, tiempo, o recursos
necesarios para otorgar el nivel de confianza requerido.
o Identidad o ubicación de los riesgos más importantes dentro del modelo
del proyecto. Por ejemplo, un análisis de sensibilidad en un análisis de
riesgos de costos, o un análisis de criticidad en un análisis de riesgos de
itinerario.
• Análisis cuantitativo iterativo de riesgos: El éxito del proceso de análisis
cuantitativo de riesgos aumenta si el proceso es recursivo a lo largo del
proyecto. Es imposible saber de antemano todos los riesgos que pueden ocurrir
en un proyecto, por lo que este análisis debe de ser repetido mientras transcurre
el proyecto. La frecuencia de este esfuerzo se determina en el proceso de

91
 planificación de gestión de riegos, pero también depende de eventos especiales
del proyecto en sí.
• Información para la planificación de respuestas: La reserva de contingencia del
proyecto global en tiempo y coste debe reflejarse en el itinerario y presupuesto.
El análisis cuantitativo otorga información que puede usarse para modificar el
plan de proyecto. Si el riesgo global de tiempo y coste indica que se requiere de
un ajuste en el alcance, los cambios del alcance son acordados y documentados y
un nuevo análisis cuantitativo de riesgos es llevado a cabo para reflejar los
nuevos aspectos del proyecto.

5.7.3 Documentando los resultados del proceso de análisis cuantitativo de riesgos:

Las reservas de contingencia calculadas en el análisis cuantitativo de riesgos de

itinerario y costos son incorporadas respectivamente, en la estimación de costos y el
itinerario para establecer una meta prudente y una expectativa real del proyecto. Dichas
reservas pueden también ser establecidas para lograr la captura de oportunidades que
son decididas como prioridades del proyecto. Si las reservas de contingencia requeridas
exceden el tiempo o recursos disponibles, se necesitarán cambios en el alcance y plan
del proyecto.

Los resultados del análisis también pueden dar más o menos urgencia a las respuestas a
los riesgos dependiendo de la probabilidad de alcanzar los objetivos o la cantidad de
reservas de contingencia requeridas para dar un nivel de confianza necesario. Los
resultados de un análisis cuantitativo deben ser guardados y pasado a la persona o
equipo responsable de la administración del proyecto dentro de la organización, para
cualquier acción posterior requerida.

5.8 PLANIFICACIÓN DE RESPUESTAS:

El proceso de planificación de respuestas a los riesgos se encarga de determinar

repuestas efectivas adecuadas a la prioridad de tanto riesgos individuales como globales,
que aumenten las posibilidades de éxito del proyecto. Para ello toma en cuenta las
actitudes de los patrocinadores ante los riesgos y las convenciones especificadas en el
plan de gestión de riesgos, además de restricciones y suposiciones que se determinaron
en la identificación y análisis de los riesgos. Una vez identificados, analizados y
priorizados los riesgos, se deben desarrollar planes para tratar cada riesgo que se
consideren importantes, ya sean porque se traten de amenazas u oportunidades.

La planificación implica concordancia de los responsables en las acciones que se

tomarán y los potenciales cambios en el presupuesto, itinerario, recursos, y alcance que
puedan causar. Las respuestas de contingencia se necesitan ejecutar el tiempo óptimo,
por lo que las especificaciones de respuestas para cada riesgo deben incluir una
descripción de cualquier condición causante correspondiente.

La responsabilidad de monitorear condiciones e implementar acciones correspondientes

debe ser claramente asignada. Cada riesgo se debe asignar a un responsable o Risk
Owner en el proceso de identificación de riesgos, y cada respuesta correspondiente debe
asignarse a un responsable de acción o Risk Action Owner. La diferencia radica en que
un Risk Owner debe de preparar una respuesta efectiva para su riesgo, mientras que el

92
Risk Action Owner se encarga de ejecutar las tareas que requiera la respuesta, de la
manera planeada y en el tiempo planeado; dichos roles para el mismo riesgo pueden
asignarse a una misma persona o dos diferentes.

Las respuestas al ser implementadas, pueden tener efectos potenciales en los objetivos
del proyecto, y como tales, pueden generar riesgos adicionales. A éstos se les conoce
como riesgos secundarios y deben de ser analizados y planificados de la misma manera
que se trataron los riesgos iniciales. Nunca es factible o aún deseable el eliminar todas
las amenazas de un proyecto, así como también existe un límite para administrar
proactivamente las oportunidades. Estos deben ser riesgos residuales que quedan luego
de implementadas las respuestas, y deben de ser claramente identificados, analizados,
documentados, y comunicados a todos los patrocinadores relevantes.

Todas las acciones incondicionales aprobadas de la planificación de respuestas deben de

integrarse en el plan de administración del proyecto para asegurar que se llevan a cabo
como parte normal de la implementación del proyecto. Las reglas administrativas del
proyecto y organizacionales correspondientes deben también ser invocadas, incluyendo:
• Administración de cambios en el proyecto y control de configuración
• Planificación, presupuestado, e itinerado del proyecto
• Administración de recursos
• Planificación de la comunicación en el proyecto

5.8.1 Factores críticos de éxito para el proceso de planificación de respuestas:

• Comunicación: La comunicación con los patrocinadores se debe mantener de

una manera abierta y apropiada. Los planes resultantes son difundidos y la
aprobación obtenida para asegurar una total aceptación por parte de los
patrocinadores. Además, si las causas organizacionales de los riesgos, como la
cultura, actitudes, o desacuerdos respecto a los objetivos están presentes, se
deben tratar abiertamente; esto puede requerir la participación de altos cargos de
la administración, y patrocinadores.
• Definición clara de roles y responsabilidades relativas a riesgos: El éxito de las
respuestas a riesgos depende del apoyo total participación del equipo y
patrocinadores. Las personas responsables tanto de un riesgo como de su
solución acordada deben estar al tanto de lo que se espera de ellos, y los
patrocinadores deben comprender y aceptar las necesidades y autoridades de
estos roles. La administración puede asumir la responsabilidad de un riesgo con
causas políticas u organizacionales. La administración con más experiencia debe
aprobar y rastrear reservas de contingencia para los riesgos.
• Especificar la duración de las respuestas: Las respuestas acordadas se deberán
integrar al plan de administración del proyecto y por ende ser agregadas al
itinerario y asignadas para llevarse a cabo. Las respuestas que dependen de
condiciones inciertas deben monitorearse para ejecutarse si las condiciones lo
garantizan.
• Suministrar recursos, presupuesto, e itinerario para las respuestas: Cada
respuesta debe ser planeada al detalle en concordancia con la metodología del
proyecto, e integrada en el plan de administración del proyecto. Esto implica
estimar los recursos, costos, y duración; actualizando el presupuesto e itinerario;
obtener la aprobación de la administración; y obtener el compromiso de los Risk
Owners y Risk Action Owners. El rol de la administración en esta fase es vital

93
 para apoyar al administrador del proyecto en desarrollar respuestas a los riesgos
y autorizar los recursos correspondientes.
• Tratar las interacciones de riesgos y repuestas: Las respuestas se desarrollan para
tratar riesgos relacionados por sus causas, efectos o causa común, en donde la
categorización de los riesgos puede ayudar a identificar y tratar esta situación.
También hay la necesidad durante el proceso de planificación de respuestas, de
considerar los riesgos agregados durante el proceso de análisis cuantitativo de
riesgos, y luego desarrollar respuestas genéricas de ser posible. Otro efecto de
interacción que puede pasar es que un riesgo, si llegase a ocurrir, puede afectar
la probabilidad o impacto de otros riesgos. Decidir la estrategia de las respuestas
puede requerir de un compromiso, dado que algunas respuestas propuestas
pueden ser mutuamente excluyentes o contraproducentes, o comprometer otros
aspectos del proyecto. El desafío en la planificación de respuestas entonces,
necesita controlar los efectos potenciales de las estrategias desarrolladas para
tratar al riesgo; si este aspecto se pasa por alto, el nivel total de amenaza al
proyecto puede aumentar, o comprometerse el potencial de las oportunidades.
• Asegurar respuestas adecuadas, oportunas, efectivas y acordadas: Idealmente,
las respuestas deben de ser apropiadas, oportunas, factibles, efectivas respecto al
costo, alcanzables, acordadas, asignadas y aceptadas. Cualquier plan de
respuesta propuesto debe evaluarse de acuerdo a los siguientes criterios:
o Consistencia con los valores organizacionales, objetivos, y expectativas
de los patrocinadores
o Factibilidad técnica
o Habilidad del equipo o Risk Action Owner fuera del proyecto de llevar a
cabo las acciones correspondientes
o Balance entre el impacto global de la respuesta en los objetivos y la
mejora del perfil del riesgo del proyecto
• Tratar tanto las amenazas como las oportunidades: La planificación de
respuestas a riesgos debe combinar respuestas que traten las amenazas al
proyecto, así como las oportunidades, en un plan integral. Si las amenazas u
oportunidades no son tratadas del todo, el grupo combinado de estrategias de
respuesta estará incompleto e inclusive puede ser no válido.
• Desarrollo de estrategias antes de respuestas tácticas: La planificación de
respuestas al riesgo deben llevarse a cabo con mente abierta en vez de adoptar la
primera respuesta que parezca factible. Las respuestas deben planearse en un
nivel general, estratégico, y la estrategia validada y acordada, previo a
desarrollar el enfoque táctico detallado. Una vez que las respuestas son
planificadas a un nivel estratégico, deben expandirse a acciones al nivel táctico y
ser integradas al plan de administración del proyecto. Esta actividad puede
general riesgos secundarios adicionales, que necesitarán ser tratados.

5.8.2 Estratégicas de respuestas:

El administrador del proyecto debe desarrollar estrategias de respuestas para riesgos

individuales, grupos de riesgos, y riesgos globales. Los patrocinadores afectados deben
involucrarse en determinar las estrategias; una vez seleccionadas, necesitan estar de
acuerdo con la entidad que aprueba dichas estrategias. Existen cuatro estrategias que
tratan riesgos individuales de amenazas y oportunidades, que son descritas en las cuatro
primeras definiciones a continuación:

94
 • Evitar una amenaza y explotar una oportunidad: Esta estrategia requiere de
acciones necesarias para tratar una amenaza u oportunidad, para así asegurar que
la amenaza no ocurra o no tenga efectos en el proyecto, o que la oportunidad
ocurra y el proyecto pueda aventajarse de ello.
• Transferir una amenaza o compartir una oportunidad: Esta estrategia implica la
transferencia a una tercera parte que esté mejor posicionada para tratar un riesgo
o oportunidad en particular.
• Mitigar una amenaza e intensificar una oportunidad: La mitigación o
intensificación son las estrategias más aplicables y utilizadas. La idea se basa en
identificar acciones que reduzcan la probabilidad y/o impacto de una amenaza, y
aumenten la probabilidad y/o impacto de una oportunidad.
• Aceptar una amenaza o una oportunidad: Esta estrategia se aplica cuando otras
estrategias no se consideran aplicables o factibles. La aceptación implica no
tomar medidas a menos que el riesgo llegue a ocurrir; para tal caso se
desarrollarán planes de contingencia o retiro, a ser implementados si el riesgo se
presenta.
• Aplicar estrategias de respuestas a riesgos globales del proyecto: Además de
responder a riesgos individuales, las cuatro estrategias de respuestas pueden
aplicarse para tratar riesgos globales del proyecto, como:
o Cancelar el proyecto, como último recurso, si el nivel global del riesgo se
mantiene intolerable.
o Crear una estructura de negocios en la cual en cliente y el proveedor
compartan el riesgo.
o Volver a planear el proyecto o cambiar el alcance y límites del proyecto,
por ejemplo modificar las prioridades del proyecto, asignación de
recursos, calendario de entregas, etc.
o Seguir con el proyecto a pesar de estar expuesto a un riesgo que exceda
el nivel deseado.

5.8.3 Técnicas y herramientas para el proceso de planificación de respuestas:

Existen cuatro categorías de técnicas y herramientas, que son:

• Herramientas de creatividad para identificar potenciales respuestas
• Herramientas de apoyo a decisiones para decidir una respuesta potencial óptima.
• Técnicas de implementación de estrategias para pasar una estrategia a acción.
• Herramientas para transferir control al proceso de sondeo y control de riesgos.

Dichas categorías de herramientas pueden ser utilizadas respectivamente para identificar

respuestas potenciales, seleccionar la respuesta más apropiada, trasladar la estrategia en
planificación, y asignar las acciones correspondientes:
• Identificación de respuestas: La planificación de respuestas aprovecha la
información disponible sobre los riesgos potenciales y ayuda a determinar el
conjunto ideal de respuestas. Es por esto que debería involucrar a expertos en la
materia y emplear técnicas de creatividad para explorar todas las opciones. La
planificación del proyecto y ejecución de técnicas son necesarias para evaluar
los efectos potenciales de las diversas opciones en los objetivos del proyecto.
• Selección de respuestas: Una vez el conjunto de respuestas potenciales son
evaluados y establecidos, las técnicas de apoyo de decisiones necesita aplicarse
para escoger el mejor subconjunto posible de respuestas. En el proceso de
selección debe tenerse en cuenta el costo de las respuestas, el impacto en los
95
 objetivos, la incertidumbre de los resultados y posibles riesgos secundarios y
residuales. Los procesos de identificación de riesgos, análisis cuantitativo de
riegos, y planificación de respuestas pueden requerir ser aplicados al plan de
administración resultante y los riesgos secundarios y residuales a los que
conlleva. Este enfoque recursivo continúa hasta que todos los riesgos
individuales son considerados aceptables y el riesgo global está bajo un límite
definido.
• Planificación de acciones: Las herramientas de planificación de proyectos se
usan para volver las estrategias escogidas en acciones concretas e integrarlas a
los planes existentes. Las acciones correspondientes pueden ser incondicionales
o sujetas a acciones desencadenante y predefinidas como estrategias de
respuestas de contingencia.
• Asignación de responsabilidades y propiedades: El administrador del proyecto
necesita utilizar procesos de asignación de recursos para asegurar la
disponibilidad de un responsable para cada riesgo y para cada acción, de modo
que cada riesgo asociado sea gestionado y cada respuesta respectiva se lleve a
cabo de manera efectiva y oportuna. Para que un sondeo pueda identificar
inminentes ocurrencias de eventos, cada estrategia de respuesta de contingencia
debe incluir un grupo de condiciones provocantes. La responsabilidad de
sondear estas condiciones se deben asignar en el proceso de planificación de
respuestas y gestionar en el proceso de monitoreo y control de riesgos. La
definición estratégica de repuestas debe incluir criterios medibles para el éxito
de la respuesta. Los Risk Action Owners deben sondear sus riesgos asignados,
tomar acciones acordadas, y dar a los Risk Owners información del estatus o
cambios en riesgos. Los Risk Owners deben evaluar la efectividad de cualquier
acción, decidir si se requiere de acciones adicionales, y mantener al
administrador del proyecto informado.

5.8.4 Documentar los resultados del proceso de planificación de repuestas:

La planificación de respuestas se basa en la información puesta en el registro de riesgos

durante los procesos de identificación de riesgos y análisis. La información de
respuestas correspondientes suele ser el plan de respuestas a los riesgos, a pesar que
pueda ser una parte integral del registro de riesgos:
• Añadir las respuestas al registro de riesgos: La información relacionada con
respuestas para cada riesgo de debe poner en el registro de riesgos y actualizar
con regularidad. Cada patrocinador interesado debe poder acceder rápidamente a
la información para verificar sus responsabilidades y administrar riesgos de
acuerdo al plan de respuestas. El grupo de riesgos residuales y sus prioridades
son también identificados y grabados.
• Añadir las respuestas correspondientes al plan de administración del proyecto:
Al desarrollar el grupo detallado de respuestas, las implicaciones relativas al
proyecto son evaluadas para incluirlas en el plan de administración del proyecto.
Esto incluye costos, asignación de recursos, detalles de itinerario, y cambios en
la documentación. Hasta que estos cambios no se aprueben formalmente junto
con los riesgos adicionales que pueden conllevar, la planificación de respuestas
no se puede dar por completa.
• Revisar y documentar exposiciones previstas: Una vez que las respuestas son
definidas e integradas en el plan de proyecto, los riesgos residuales individuales
y globales relacionados a dicho plan son evaluados para determinar si se

96
 requiere la planificación de respuestas adicionales. Esta evaluación debe dar una
estimación de la situación post-respuesta y de la potencial mejora de la
exposición al riesgo asumiendo que las respuestas propuestas son efectivas. La
evaluación debe documentarse.

5.9 MONITOREO Y CONTROL DE RIESGOS:

La efectividad de la gestión de riesgos depende en la manera en la que se llevan a cabo

los planes aprobados, los cuales deben ser ejecutados correctamente, revisados, y
actualizados correctamente. Si todo esto ocurre, el esfuerzo invertido tendrá recompensa
del éxito y que los proyectos futuros se beneficiarán de la experiencia acumulada.

El monitoreo y control de riesgos se aplica para rastrear riesgos identificados,

monitorear riegos residuales, identificar nuevos riesgos, asegurar que los planes de
respuestas se ejecutan al tiempo adecuado, y evaluar la efectividad por todo el proyecto.
Además de ello, se deberá revisar la efectividad de los procesos de gestión de riesgos
para brindar mejoras a la administración del proyecto.

Para cada riesgo o conjunto de riesgos que tenga una respectiva respuesta planteada, el
correspondiente grupo de acciones desencadenantes debe especificarse. Es deber del
responsable de la acción el asegurar que estas condiciones se monitoreen efectivamente
y que las acciones correspondientes se ejecutan tal como se definieron, de manera
oportuna. Una vez completo el proceso de planificación de respuestas, toda acción de
respuesta incondicional aprobada debe definirse e incluirse en el plan de administración
del proyecto.

La primera acción del monitoreo y control es de revisar si se da el caso y tomar acción

en caso necesario, como el invocar al proceso de administración de cambios respecto a
alguna acción que falte. Esto asegurará que las acciones acordadas se llevan a cabo con
el esquema normal de ejecución del proyecto. Los Risk Owners y Risk Action Owners
deben ser avisados de cambios que afecten sus responsabilidades. Se necesita mantener
comunicación efectiva con el administrador del proyecto para que los patrocinadores
designados acepten la responsabilidad de controlar los resultados potenciales de los
riesgos específicos, aplicar sus mejores esfuerzos en rastrear las asociadas condiciones
desencadenantes, y llevar a cabo las respuestas acordadas de manera oportuna.

Además de las respuestas a las condiciones desencadenantes, el proceso de planificación

de respuestas brinda un mecanismo para medir efectivamente la respuesta. El Risk
Action Onwer debe mantener al Risk Owner al tanto de las acciones de respuesta para
que el Risk Owner pueda decidir si el riesgo fue efectivamente tratado o si se requerirá
planificar e implementar acciones adicionales.

Mientras el proyecto avanza, se va poniendo disponible información adicional y el

entorno del proyecto puede cambiar como algunos riesgos pueden ocurrir, previstos o
no, y otros pueden volverse o dejar de ser relevantes. La planificación deberá, por ende,
mantenerse al tanto, y el administrador del proyecto asegurar que la reevaluación del
riesgo periódico, incluyendo identificación de riesgos, análisis, y la planificación de
respuesta, se repita en intervalos razonables, o en respuesta a eventos puntuales, sin

97
generar demasiadas sobrecargas administrativas. Las razones más comunes para las
reevaluaciones de riesgos son:
• Ocurrencia de un riesgo inesperado o importante
• Necesidad de analizar una petición de cambio compleja
• Evaluación de fin de fase
• Replanteamiento del proyecto o elaboración de un plan mayor
• Revisión periódica para asegurar que la información permanece vigente

Si se dan cambios organizacionales mayores, la planificación de gestión de riesgos

necesitará ser revisada antes de reevaluar los riesgos. Aparte de las revisiones regulares,
las auditorías periódicas deben determinar fuerzas y debilidades de los riesgos en curso
del proyecto, lo que implica identificar cualquier barrera para la efectividad o claves
para el éxito de la gestión de riesgos, reconocimiento del cual puede conllevar a mejoras
en la gestión de riesgos de los proyectos actuales o futuro.

Al final del proyecto, se deberá llevar a cabo un análisis integrado del proceso de
gestión de riesgos enfocado en mejoras del proceso a largo plazo. Este análisis
consolida los hallazgos de las auditorías periódicas para identificar lecciones que serán
aplicables en general a una gran porción de los proyectos de la organización en el
futuro, como niveles apropiados de recursos, tiempos adecuados para el análisis, uso de
herramientas, nivel de detalle, etc.

En el cierre del proyecto, el administrador deberá asegurarse que se ha dado una

descripción del cierre de cada riesgo en el registro de riesgos, como por ejemplo
mencionar qué no ocurrió, ocurrió y se ejecutó el plan de contingencia, o qué ocurrió y
su impacto en el alcance. El resultado de la auditoría del proceso de gestión de riesgos
debe consolidarse con información específica respecto a la experiencia del proyecto con
los riesgos, y debe resaltarse cualquier pauta aplicable para la organización y las
acciones potenciales pospuestas. Esto puede conllevar a una actualización de los
correspondientes bienes del proceso organizacional.

5.9.1 Factores críticos para el éxito del proceso de monitoreo y control de riesgos:

Los factores críticos de éxito están relacionados al mantenimiento de la conciencia de

riesgo a lo largo del proyecto e incluye las características y capacidades siguientes:
• Integrar el monitoreo y control de riesgo con monitoreo y control del proyecto:
Desde el comienzo, el plan de administración del proyecto debe incluir las
acciones requeridas para monitorizar y controlar los riesgos; esto debe
establecerse al comienzo del ciclo de planificación del proyecto, y luego
ajustado en función de la añadidura de decisiones de planificación de respuestas
a riesgos, por ejemplo las acciones asociadas con monitorear condiciones
métricas específicas. Una vez realizada la planificación, el itinerario del
proyecto debe incluir todas las acciones acordadas de respuesta, para que puedan
ser desarrolladas como parte normal de la ejecución del proyecto y rastreadas
debidamente.
• Monitorear continuamente las condiciones desencadenantes de los riesgos: La
planificación de respuestas tendrá definida un grupo de acciones a realizarse
como parte del itinerario del proyecto, así como acciones de las que su ejecución
depende en una condición desencadenante predefinida. Revisar por riesgos
específicamente definidos que pueden desencadenar respuestas condicionales es

98
 responsabilidad del Risk Action Owner, en cercana colaboración con el Risk
Owner bajo la autoridad general del administrador del proyecto.
• Mantener la conciencia de riesgo: Los reportes de gestión de riesgos deben ser
factores regulares en cada agenda de reunión de estatus para asegurar que todos
los miembros del equipo sean concientes de la importancia de la gestión de
riesgos y que sea integrado completamente en todas las decisiones
administrativas del proyecto. El patrocinador de alto nivel del proyecto puede
necesitar reportes regulares de riesgos y respuestas planeadas para asegurar que
los demás patrocinadores sean concientes de la importancia de mantener un
enfoque en el riesgo. La retroalimentación del patrocinador motiva también al
equipo del proyecto al demostrar interés de alto nivel en la gestión de riesgos. La
percepción de efectividad de gestión de riesgos del patrocinador se condiciona
en parte por la forma en la que los riesgos se tratan a medida que se producen, y
por el número de características de dichos eventos. Es por ello crítico que,
cuando un riesgo ocurra, la información sobre el evento, así como el progreso y
efectividad de las respuestas, sean comunicadas en intervalos regulares y de
manera honesta adecuada a la necesidad de cada patrocinador. Esto deberá ser
soportado por un plan de comunicaciones bien ejecutado.

5.9.2 Técnicas y herramientas para el proceso de monitoreo y control de riesgos:

Además de las capacidades de control y monitoreo de la administración del proyecto

estándar, el monitoreo y control de riesgos requiere un enfoque en las herramientas que
soportarán los factores clave para seguir los riesgos globales, así como los individuales:
• Administrar las reservas de contingencia: Las reservas pueden haber sido
asignadas separadamente para cubrir riesgos de costos y tiempo. Se requieren
técnicas que permitan al administrador del proyecto evaluar en cualquier punto
del proyecto si otorga el nivel de confianza requerido para su éxito. Las
herramientas para administrar los márgenes de tiempo deben integrarse
estrechamente a las técnicas de itinerado del proyecto, mientras que las
herramientas para administrar costos deben ser compatibles con las prácticas
financieras que se utilicen. Se requieren herramientas para identificar tendencias
y poder predecir resultados futuros para determinar si las reservas serán
suficientes. Las herramientas son también requeridas para rastrear el progreso y
gasto de manera conjunta.
• Rastrear condiciones desencadenantes: Las condiciones desencadenantes las
métricas correspondientes se definen en el proceso de planificación de
respuestas. Las herramientas son requeridas para evaluar y seguir dichas
condiciones contra la línea base del proyecto o los límites especificados, basados
en el estatus actual. Pueden usarse para obtener información de riesgos
relacionados a los entregables, como el desempeño, así como también en los
rasgos relativos al proyecto, como el tiempo y costo.
• Rastrear riesgos globales: Las herramientas se requieren para poder determinar
mientas se desarrolla el proyecto, si las respuestas están produciendo el efecto
esperado en el nivel global del riesgo del proyecto.
• Rastrar conformidad: Para monitorear la calidad de la ejecución de los procesos
y planes de riesgos, un grupo de métricas de calidad, como el nivel de variación
respecto a la línea base, deben rastrearse y anotarse. Dichas métricas serán
normalmente definidas en el plan de gestión de riesgos.

99
5.9.3 Documentar los resultados del proceso de monitoreo y control de riesgos:

La acción de control final del monitoreo y control de riesgos es grabar los datos actuales
para usos futuros, que incluye toda la información relevante sobre gestión de riesgos de
todo el proyecto. La definición de lo que esta información deberá contener y el
mecanismo de almacenaje deben ser previamente especificados en el plan de gestión de
riesgos. La idea es asegurar que la información de gestión de riesgos significativa se
grabe para brindar datos concretos al proceso de lecciones aprendidas para su inclusión
en documentos, reportes u otros vehículos de comunicación. La información típica
incluye:
• Para cada riesgo identificado o tipo de riesgo, si ocurrió, y en caso haya
ocurrido, cuándo y a qué frecuencia. Todos los datos relevantes deben grabarse:
impacto, efectividad de detección y de respuesta, y cualquier acción adicional no
planeada que se haya llevado a cabo.
• Efectividad de evasión o explotación de acciones.
• Efectividad de transferencia o repartición de acciones.
• Riesgos inesperados o no documentados que ocurrieron, y datos sobre ellos.
• Efectividad de mitigación de riesgos y acciones de mejora.
• Ocurrencia de amenazas u oportunidades aceptadas.

Se deberá brindar información consolidada al nivel de esfuerzo realizado, así como los
costos y beneficios de las actividades de gestión de riegos. Esta información necesitará
ser archivada e indexada de manera que facilite la recuperación para revisiones fáciles
durante el proyecto, al cierre, y para proyectos futuros, cuando la necesidad aparezca.

100
CAPÍTULO 6: ESTÁNDAR PRÁCTICO PARA LA
GESTIÓN DEL VALOR OBTENIDO

6.1 INTRODUCCIÓN:

La utilidad del Earned Value Management (EVM) surge a partir de la necesidad de una
constante retroalimentación o feedback en la administración de un proyecto para un
mejor y más cercano seguimiento en su desarrollo, el cual permite ‘visualizar’ de
manera clara los puntos en los que se encuentra el avance y hacia donde se proyecta. El
EVM facilita la realización al mismo tiempo de las gestiones del alcance, itinerario y
costos del proyecto, resolviendo dudas importantes para la gestión como por ejemplo el
tiempo que ha tomado realizar una tarea específica o todo el proyecto hasta el momento,
con cuántos recursos se han hecho dichas tareas, en cuánto tiempo se acabaría el
proyecto al ritmo actual, harían o no falta más recursos para acabar el proyecto, se
podrán alcanzar los objetivos finales o no, entre otros.

Como una herramienta imprescindible para la gestión de proyectos, no únicamente nos

brinda un reporte sobre el estado de éste y su proyección, sino que en caso de haber sido
detectados errores o contratiempos, facilita también detalles relevantes para una
posterior toma de decisiones como el porqué de los problemas ocurridos, si el problema
es crítico o no para lograr los objetivos del proyecto, y de qué manera se podría
recuperar el buen ritmo de desarrollo del proyecto. Su presencia en las diferentes fases
del proyecto es más útil cuado éste se encuentra en las fases de planeamiento y control,
debido a que el EVM es una metodología para medir el nivel de desempeño y por ende
está directamente relacionado con actividades de medición, análisis, reporte y
predicción.

Al comienzo del proyecto, en la etapa de planeamiento, el EVM establece una línea

base de medición de la ejecución o Performance Measurement Baseline (PMB), la cual
tiene como finalidad establecer en números el nivel de desarrollo teórico que debería
tener el proyecto en términos de coste, trabajo y alcance a lo largo del tiempo esperado,
y sobre la cual se harán las futuras mediciones y valoraciones.

Para poder realizar los trabajos, disponer del personal más eficientemente y hacer el
control del avance más sencillo, se realizan subdivisiones denominadas estructura de
descomposición del trabajo o Work Breakdown Structure (WBS). A su vez se realizan
descomposiciones del personal en equipos especializados de trabajo formados por
grupos o inclusive por una sola persona; a éstas se le denominan estructura de
descomposición de la organización u Organization Breakdown Structure (OBS).

101
 Gráfico 1: Conformación de los Control Accounts

Una vez determinadas ambas estructuras, se realiza la asignación de tareas a cada

equipo en la que cada tarea no puede ser realizada por más de un equipo para no tener
ambigüedad en las responsabilidades, lo cual es negativo; pero un equipo o grupo de
trabajo sí pueden tener asignados una o más tareas. A cada tarea con un grupo asignado
se le denomina Control Account, y es la mínima unidad a partir de la cual se realizarán
las mediciones en el EVM, siéndole asignados valores al trabajo a realizar para
finalizarlo, recursos necesarios y tiempo para su desarrollo.

Para realizar las mediciones del estado del proyecto, el EVM utiliza tres elementos que
son los presentados a continuación:
• Planned Value (PV): Es un valor numérico que indica el estado teórico en el que
debería encontrarse el desarrollo del proyecto en el momento del sondeo, y es el
valor a partir del cual se establece el PMB y sobre el cual serán comparados los
siguientes valores de la medición. Es también conocido como el costo
presupuestado del trabajo planeado o Budgeted Cost of Work Scheduled
(BCWS), y únicamente puede variar si se producen cambios en el itinerario o
coste del proyecto.
• Earned Value (EV): Es otro valor numérico que refleja el trabajo realizado del
proyecto al momento de la medición, también se conoce como el costo
presupuestado del trabajo realizado o Budgeted Cost of Work Performed
(BCWP) y sirve para ver la diferencia únicamente de trabajo hecho hasta el
momento respecto al planeado hasta ese mismo momento.
• Actual Cost (AC): Este tercer dato refleja información más real sobre el estado
de desarrollo del proyecto debido a que mide la cantidad de trabajo realizada
102
 hasta el momento junto con el valor real de presupuesto gastado hasta entonces,
en términos de recursos. Se le denomina también el costo actual del trabajo
realizado o Actual Cost of Work Performed (ACWP). Cuando se aplica el
Earned Value para gestionar el progreso de un proyecto, es muy importante que
la empresa u organización en cuestión tenga un sistema de rastreo del dinero y
recursos que se van utilizando, para así poder medir correctamente y tener datos
más fieles a la realidad.

Una correcta medición es vital para un análisis real del estado del proyecto, y para ello
se debe asegurar que los métodos de planificación y sondeo del progreso del proyecto
sean lo más objetivos posibles y apropiados para el trabajo, como por ejemplo las horas
de trabajo realizadas, las cantidades de materiales, el equivalente de los recursos
destinados en costo, etc.

6.2 TÉCNICAS DEL EVM:

Las técnicas que serán utilizadas en las mediciones del progreso del trabajo son
escogidas en la fase de planificación del proyecto y sientan las bases del éxito en las
consiguientes fases de ejecución y control. Como se ha mencionado previamente, dichas
técnicas se deben escoger basándose en las características clave del trabajo, que son la
duración del esfuerzo y la tangibilidad de los resultados.

Todos los trabajos o esfuerzos realizados con la finalidad de llegar a un objetivo

inmediato o producto o servicio final, que pueden ser planificados y medidos, son
denominados esfuerzo discreto o Discrete Effort; en contraparte, todo esfuerzo que no
es divisible en esfuerzos discretos pero que están relacionados directamente con éstos es
el esfuerzo repartido o Apportioned Effort. Por último, existe un tercer tipo de esfuerzo
que es de soporte, que no tiene como finalidad la obtención de un resultado tangible, es
el grado de esfuerzo o Level of Effort.

El trabajo realizado es medido periódicamente, ya sea en semanas o meses, y las

técnicas para realizar dichas medidas dependen de la cantidad de periodos que dure un
proceso. Si la duración de un Discrete Effort es de hasta dos periodos de medición, se le
aplicará la técnica de Fixed Formula, en la cual se hace la suposición que un porcentaje
del trabajo total se realizó puntualmente en su comienzo, y el resto, puntualmente en el
final. En caso que un Discrete Effort tenga dure más de dos periodos, se aplican otras
técnicas de medida, como son el Percent Complete y Weighted Milestone. Las técnicas
previamente mencionadas se explican a continuación:
• Fixed Formula: Este es el método utilizado para esfuerzos de hasta dos periodos
de duración, y como se ha expuesto anteriormente, consiste de dos únicas
mediciones, en donde primeramente se determinan dos porcentajes para luego
asumir esta primera cantidad como el porcentaje de trabajo completado en la
primera medición que se realiza al comienzo del primer periodo de duración del
esfuerzo, aún cuando en ese preciso instante no se haya realizado trabajo alguno.
El otro valor, que sumado al primero dan 100%, se toma como el trabajo
realizado desde la medición anterior hasta esa medición, que se realiza cuando
finaliza el segundo periodo del esfuerzo. Si utilizamos el 50/50 por ejemplo,
estaremos asumiendo dos mediciones, una realizada al comienzo del primer
periodo del esfuerzo en donde se realizó el 50% del trabajo total, mientras que el

103
 otro 50% se asume realizado al final del segundo periodo, en la segunda
medición.
• Weighted Milestone: Esta técnica es más apropiada para realizar medidas en
esfuerzos que se extienden por más de dos periodos de duración. El Weighted
Milestone divide la duración total de todo el esfuerzo en segmentos en los que al
final de cada uno se hará una medición, asignando un porcentaje del total del
trabajo a cada segmento.
• Percent Complete: Esta técnica es la más simple de todas las que se realizan
sobre un esfuerzo debido a que directamente en cada periodo de medición, el
trabajo medido es directamente el porcentaje de trabajo planeado hasta ese
momento. El único problema de esta técnica es que los valores pueden no ser
muy cercanos a la realidad, por lo que se recomienda que si se pudieran hacer
mediciones reales del trabajo para obtener mejores datos, éstos serían más
fiables.
• Apportioned Effort: Cuando una tarea tiene una relación directa con otra tarea a
través del soporte que ésta primera le brinda, entonces el Earned Value de la
tarea de soporte deberá se medido con la misma técnica con la que se hace la
medición de la tarea que recibe el soporte. La técnica dicta que cada vez que
cuando se realice una medición, lo adecuado es que el valor de la tarea de
soporte sea directamente proporcional al 10% del valor de la tarea principal.
• Level of Effort: El Level of Effort es un método que sirve para medir el Earned
Value realizado por tareas que no tienen como finalidad una salida tangible o
producto en concreto pero que a su vez consumen tiempo y recursos del
proyecto en cuestión. A estas tareas se les aplica esta técnica debido a que su
trabajo realizado no puede ser medido de una manera concreta al tratarse
únicamente de un trabajo subjetivo, y la medición consiste en asignarles
directamente un valor en cada período de medición.

6.3 ANÁLISIS Y PREDICCIÓN CON EL EVM:

Como se había mencionado al comienzo, el Earned Value Management sirve para hacer
una valoración con datos reales del avance del proyecto y predicciones hacia el futuro,
permitiendo a la persona o equipo de gente que gestiona el proyecto tener respuesta a
preguntas importantes sobre el desarrollo tales como:
• ¿Cómo marcha el proyecto con respecto al tiempo previsto?
• ¿Cuándo se acabará si se continúa al mismo ritmo de progreso?
• ¿Cuánto se ha gastado hasta el momento?
• ¿Hemos gastado más o menos de lo calculado?
• ¿Se llegará a finalizar el proyecto con el presupuesto inicial?

Para ello el Earned Value maneja una serie de variables numéricas que facilitan el
cálculo de los valores que servirán para analizar y predecir el rendimiento del proyecto,
tanto del punto de vista del tiempo como del dinero. Entre las variables que miden el
desarrollo temporal del proyecto, están:
• Schedule Variance (SV): Es una variable que indica si se ha realizado más o
menos trabajo del previsto hasta la fecha, y se calcula restando Planned Value
del Earned Value, de modo en que un valor positivo indica más trabajo
realizado, lo que se traduce en más avance del previsto, mientras que un valor
negativo representa que se ha efectuado menos trabajo hasta la fecha, y el valor
104
 cero, de que las tareas se han realizado de acuerdo a los plazos planificados
inicialmente. Se puede también expresar el valor del SV en porcentajes, que se
calcula a partir de dividir el Schedule Variance obtenido entre el Planned Value:

SV = PV - EV

SV(%) = SV / PV

• Schedule Performance Index (SPI): Es un valor normalizado que representa la

eficiencia con la que se está utilizando el tiempo para realizar las tareas del
proyecto, el SPI se obtiene al dividir al Earned Value entre el Planned Value, en
el cual un valor superior a la unidad representa un balance positivo mientras que
si esmenor a uno indica una valoración negativa del trabajo realizado respecto al
previsto hasta el momento:

SPI = EV / PV

• Time Estimate at Completion (EACt): Sirve para calcular el tiempo total que
tomará finalizar todo el proyecto si es que la tendencia de realización del trabajo
actual medida, se mantuviese a lo largo de todo el proyecto. El resultado saldrá
en las mismas unidades de tiempo en las que se ingrese el tiempo planificado de
duración de todo el proyecto:

EACt = (BAC / SPI) / (BAC / Tproyecto)

Si un proyecto tiene una duración planeada de un año, pero su SPI es de 0,5 (se realiza
la mitad del trabajo planeado para un tiempo dado), entonces en ese instante el EACt
sería de dos años, o en otras palabras, si se siguiese al mismo ritmo de trabajo por el
resto del proyecto, tardará dos años en acabarse. Cabe mencionar que siempre es mejor
contrastar estos datos con otros más específicos sobre el avance porque no siempre un
valor de EACt representa lo que indica, debido a que se puede tener el caso de algunos
procesos hechos rápidamente y otros lentos y aún así tener un resultado aceptable.
Del mismo modo en que se hacen cálculos para determinar el avance y la efectividad en
el tiempo, existen a su vez variables que ayudan a calcular el gasto realizado y su
respectiva efectividad, entre otros, y estas son:
• Cost Variance (CV): Es un indicador que refleja la cantidad de dinero en
diferencia que se ha gastado a más o menos en el proyecto hasta el momento de
la medición. Su valor se calcula restado al Earned Value el Actual Cost, de
manera que un resultado positivo indique que se ha gastado menos dinero del
previsto en hacer la misma carga de trabajo, mientras que un valor negativo hará
referencia a un mayor gasto del planeado. De la misma manera que el SV, el CV
también tiene una forma porcentual, que consiste en dividir el Earned Value al
valor de CV.

CV = EV - AC

CV(%) = CV / EV

• Cost Performance Index (CPI): El Cost Performance Index es un valor

porcentual, que mide el nivel de eficiencia con el que se ha gastado o utilizado el

105
 dinero del proyecto hasta el instante de la medición. Se calcula dividiendo el
Earned Value entre el Actual Cost, de manera que si se obtiene un porcentaje
mayor a 100, significa que se está utilizando de manera eficiente el dinero o que
se está gastando menos de lo previsto en hacer unas determinadas tareas,
mientras que lo contrario ocurrirá si el porcentaje es menor al 100%:

CPI = EV / AC

• To-Complete Performance Index (TCPI): Es una variable muy útil dado que no
sólo representa un estado del momento sino una condición para el futuro del
proyecto; el TCPI es un número normalizado que representa la eficiencia que ha
de tener el proyecto desde el momento de la medición hasta el fin del proyecto
para poder conseguir el nivel de presupuesto total planeado. Su cálculo se hace
restando al Budget at Completion el Earned Value (que representa el trabajo
pendiente) y dividiéndolo por la resta del BAC con el Actual Cost (que
representa el presupuesto pendiente):

TCPI = (BAC - EV) / (BAC - AC)

• Estimate at Completion (EAC): El Estimate at Completion responde a la

pregunta de cuánto va a acabar costando todo el proyecto si se mantiene el
mismo ritmo de gastos hasta el final del mismo, o lo que es lo mismo, si el CPI
continuase por lo que queda del proyecto. Se obtiene dividiendo al Budget at
Completion el Cost Performance Index:

EAC = BAC / CPI

• Variance at Completion (VAC): Es otra variable de proyección al futuro que

sirve para saber cual sería la diferencia de gastos realizados del proyecto
respecto al previsto cuando este finalice, si es que se mantiene el mismo CPI por
el resto del proyecto. Se obtiene substrayendo el Estimate at Completion del
Budget at Completion; el resultado es tal que si el valor sale negativo, indicará
que se ha gastado más de lo debido, mientras que un valor de VAC positivo por
lo contrario, indicará que el rendimiento económico del proyecto fue mejor del
planeado inicialmente. El VAC tiene también una versión porcentual, la cual se
calcula dividiendo a su valor original sobre el Budget at Completion:

VAC = (BAC - EAC)

VAC(%) = VAC / BAC

• Estimate to Complete (ETC): El Estimate to Complete responde a la pregunta de

cuánto va a costar el trabajo del proyecto desde el momento de la medición hasta
su finalización si se sigue al mismo ritmo de gastos que se tuvo desde que se
inició el proyecto hasta el momento de la medición, o en otras palabras, si
mantiene su mismo nivel de CPI durante lo que queda del proyecto. El ETC se
pude calcular de dos maneras, una en la que al Estimate at Completion se le resta
el Actual Value calculado, y otra en que se resta el Earned Value al Budget at
Completion y a esta diferencia se la divide entre el Cost Performance Index:

106
 ETC = EAC - AC

ETC = (BAC - EV) / CPI

• Administración por excepción: Es un concepto adicional que permite al Earned

Value Management ejercer una mejor efectividad en la gestión de un proyecto,
debido a que su fundamento radica en que el administrador o equipo de
administradores del proyecto se dediquen al desarrollo del mismo y únicamente
hagan uso de los mecanismos de gestión y cambios cuando éstos sean
necesarios. Tanto la división del trabajo en partes menores, también conocida
como Work Breakdown Structure (WBS), como las mediciones periódicas, son
fundamentales para la obtención de datos más precisos para aplicar la
administración por excepción.

Cuando se aplica EVM, las empresas suelen manejar diferencias en los costos de los
proyectos del 10% positiva o negativamente, como un margen aceptable en donde
pueden fluctuar los gastos respecto a lo previsto. Se tomarán medidas de cambios y
ajustes cuando el presupuesto del proyecto exceda esta cantidad, mientras que si está
por debajo, se tomará como una oportunidad y se estudiará cómo sacarle el mejor
provecho posible.

El uso del WBS permite que se haga un estudio más al detalle del progreso en trabajo y
costos de cada proceso por separado, con lo que el EVM puede utilizar la
administración por excepción tanto a estos niveles como al nivel más alto de la
jerarquía. Las técnicas de excepción no únicamente se aplicarán cuando las medidas
estén fuera del margen del 10%, sino también en casos en los que ésta siga dentro del
margen pero muestre una tendencia negativa constante desde varios periodos atrás, tanto
al nivel del proyecto en general como a nivel de procesos.

Un buen uso de ayudas gráficas siempre es necesario para poder analizar mejor las
tendencias que va tomando el desarrollo de un proyecto o proceso en el tiempo. Con la
información constante de las mediciones, se puede representar en una tabla el CPI, o el
CV, el SPI y hacer un estudio más gráfico de las proyecciones que se esperan para un
futuro o ver cómo evolucionan los cambios hechos previamente, etc. Las formas más
comunes de visualizar la información gráficamente son las curvas S, tablas con valores
y gráficos de barras.

6.4 GUÍA PARA EL USO DE TÉCNICAS CLAVES DE EVM:

Una buena utilización de las técnicas claves del Earned Value Management incrementa
la buena gestión que se hace de un proyecto, facilitando el planeamiento y control del
desempeño del trabajo y de los gastos. Las técnicas claves del EVM muestran
interdependencia entre ellas, entre las que se dividen en dos grupos principales que son
el establecimiento de una Performance Measurement Baseline (PMB) y la medición y
análisis de los datos respecto de dicha línea base. El establecimiento de una PMB consta
de cinco puntos, que se explican a continuación:
• Descomposición del alcance del trabajo a un nivel más administrable: Para que
un proyecto tenga una ejecución eficiente y efectiva es necesario una óptima
planificación y control del mismo, y para conseguirlo los alcances del trabajo

107
 son subdivididos en grupos más pequeños y manejables. Cada pequeño trabajo o
proceso maneja su propio itinerario, alcance y recursos los cuales serán
integrados para el análisis posterior con el EVM del proyecto en conjunto.
• Asignación de responsabilidades de administración específica: Cuando se realiza
un trabajo de planificación y control para la gestión de un proyecto, éste se suele
realizar sobre los distintos procesos o trabajos subdivididos llamados Control
Accounts. Es muy importante hacer una planificación con distinción de
responsabilidades en cada uno de los Control Accounts, en el que se admite que
un equipo de trabajadores tengan asignados uno o más Control Accounts, pero
no que un Control Account tenga a más de un equipo de trabajadores
responsables, debido a que si ocurre un problema, no se puede tener ambigüedad
en las responsabilidades dado que estas situaciones nunca son buenas para la
administración del proyecto y por ende se deben intentar evitar.
• Desarrollo de presupuesto gradual para cada tarea: Es importante que se haya
hecho un costeado e itinerado del alcance de trabajo para cada una de las tareas
de las que consta el proyecto. Esta información será la que aporte cada tarea para
medir el Planned Value suyo y del proyecto, y que formará parte del
Performance Measurement Baseline. Una integración vertical, que utilizan los
proyectos que aplican el Work Breakdown Structure, es fundamental para la
rápida integración de la información y un análisis más completo.
• Selección de técnicas de EVM para todas las tareas: Para realizar las mediciones
del trabajo realizado hasta el momento del sondeo en un proyecto, éste se
efectúa a cada tarea por separado, en la que cada una tendrá una técnica de
medición propia que dependerá de sus características físicas y temporales. Se da
una mayor importancia a las mediciones objetivas que se hace de una tarea con
metas concretas, en comparación a otros aspectos del progreso más subjetivos
que no son tan trascendentes. Si se trabaja con tareas que duran únicamente un
periodo habrá que hacer sólo una medición, por lo que estas tareas son de las
más preferidas; pero si la tarea es de una duración superior, se deberán utilizar
técnicas especializadas para cada tarea que aporten información concreta de los
resultados obtenidos a lo largo de su desarrollo.
• Manutención de la integridad de la PMB a lo largo del proyecto: Los cuatro
puntos previos son interdependientes entre sí, y una vez aplicados sientan las
bases para poder establecer el Performance Measurement Baseline del proyecto.
Esta línea base estará conformada por información aportada por todas las tareas
y subdivisiones del trabajo, y tomará en cuenta aspectos de itinerario, alcance y
costo, y una vez establecida se deberá mantener; únicamente se puede modificar
los valores de la PMB si ocurriesen dos situaciones. La primera es si hubiesen
variaciones en el alcance del proyecto, otros aspectos también habrían de ser
modificados y consecuentemente la PMB también se tendrá que adaptar a la
nueva situación; la otra situación es un caso extremo en que en la práctica el
proyecto simplemente no rinda al nivel esperado en la PMB y se tengan que
hacer ajustes en ámbitos como los costos o el tiempo para que se adapte a la
realidad del desarrollo del proyecto.

Una vez finalizadas las técnicas clave anteriores que se ejecutan en la planificación del
proyecto, se procede a la siguiente fase que es la medición y análisis de los datos
respecto de dicha línea base, la cual se ejecuta conjuntamente con el desarrollo y control
del proyecto, y consta también de cinco puntos que son los siguientes:

108
• Registrado del uso de recursos en la ejecución del proyecto: El costo del
desempeño que se va llevando a cabo en el desarrollo del proyecto debe de ser
medido continuamente, de manera que junto al itinerario y alcances, sean
integrados en los presupuestos del PMB. Cuanto más profundo es el nivel al que
se mide el costo, mejor será la calidad a la que se podrá gestionar el desarrollo
del mismo. Los números asociados con el valor monetario de los costos son la
forma más común de uso para efectuar los cálculos pero no es la única, porque
también se pueden realizar cálculos con respecto a otras unidades como por
ejemplo cantidades de materiales, u hora de trabajo por persona, etc.
• Medición objetiva del progreso del trabajo físico: El EVM es una herramienta
que intenta medir lo más objetivamente posible el progreso del proyecto, dado
que cuanto mejor sea su contribución a la administración, mejor será la gestión
del proyecto. Los proyectos suelen tener características de objetivos, trabajos y
alcances muy diversos, por lo que un proyecto puede ser medido constantemente
en sus objetivos tangibles conseguidos, como también puede ser muy subjetivo y
no tener resultados u objetivos físicos concretos, de manera que no se puede
aplicar el mismo tipo de medición del progreso que se aplica al caso anterior. En
este tipo de proyectos con avances poco tangibles se suelen utilizar técnicas de
sondeo de progreso y otras que no son muy precisas, pero siempre es importante
realizar las mediciones con las técnicas que se tengan a disposición, ya que es
mejor tener una idea aproximada de cómo va el avance a no tener nada que
medir ni gestionar hasta que lleguen los objetivos. Un claro ejemplo de este
último caso es cuando se trata un proyecto de desarrollo informático, en el que
únicamente se pueden medir resultados tangibles cuando este se finaliza, pero en
el proceso, se puede ir sondeando el avance de los trabajadores, las horas por
persona invertidas, la opinión de los expertos sobre el avance en curso, entre
otros.
• Reconocimiento del Earned Value según las técnicas de EVM: El trabajo físico
realizado en las tareas son reconocidos en términos de técnicas predeterminadas
que fueron escogidas durante la planificación y son incluidas en los planes de
medición para las tareas. Una correcta adherencia a los planes de medición
durante la ejecución asegurará que los valores medidos sean fieles al trabajo
realizado y puedan ser comparados con los valores planeados y costos actuales
para las tareas. Asegura también que los valores medidos son reconocidos en las
mismas unidades de medida usadas para establecer los valores planeados y
sondear costos actuales.
• Análisis y predicción del desempeño de gastos e itinerario: El desempeño de los
gastos e itinerario se deberán analizar según la regularidad e intensidad
requerida por la administración del proyecto, incluido el progreso del riesgo. El
análisis del estado del proyecto deberá ser siempre constante, utilizándose la
regla de la gestión por excepción para administrar los problemas que puedan
surgir únicamente cuando ocurran. En la etapa de planificación se determinan
ciertos valores umbrales que se utilizarán para poder controlar la buena
trayectoria de las variables del proyecto, si alguna tarea presenta indicadores que
estén por debajo de estos umbrales requerirán de gestión por excepción. Un
análisis global del proyecto puede esconder ciertos problemas internos que se
podrán entender mejor haciendo análisis por separado a cada tarea del proyecto,
en el nivel más bajo del Work Breakdown Structure. Se puede presentar el caso
de un proyecto que tenga valores de Earned Value en un rango aceptable y sin
embargo al aplicar el análisis a un nivel más bajo, se descubra que el buen

109
 desempeño de unas tareas estaban ocultando el pobre desempeño de otras, y de
no hacerse la segunda revisión se hubiese pasado por alto un problema en el
desarrollo del proyecto.
• Reporte de problemas de desempeño y/o toma de acción: La idea del EVM es
sacar el mejor rendimiento posible del manejo de costos e itinerario, pero el
buen desempeño no únicamente se da en la etapa de ejecución, sino también en
las etapas de control y planificación. La importancia del EVM es que provee al
equipo gestionador de una retro-alimentación constante e importante para
facilitar la toma de decisiones y ejecución de acciones; es necesario por ello
siempre estudiar los patrones y las tendencias que van tomando los datos del
proyecto y de las tareas en separado para que sean interpretados. Dado que la
información del EVM revela en dónde hay problemas pero no los motivos, una
vez detectados el equipo de administración deberá determinar qué es lo que esta
ocurriendo y qué medidas se tomarán al respecto. Cuando se tiene una mala
planificación, se tendrán que replantear las cosas, mientras que una mala
ejecución requerirá de una consiguiente recuperación.

110
CAPÍTULO 7: PRESENTACIÓN DEL CASO PRÁCTICO
DE APLICACIÓN

El caso de aplicación se trata de un proyecto interno de telecomunicaciones para una

empresa operadora que ofrece servicios de comunicación, en la que dicha empresa tiene
una red con tecnología HFC y otra red con tecnología SDH superpuesta. La red inicial
del operador, que es la que tiene la tecnología HFC, soporta servicios ofrecidos de
telefonía, acceso a internet, y televisión. La red de SDH por su parte, ha sido
desarrollada posteriormente para servicios de datos, y actualmente es utilizada para el
transporte de señales internas y servicio de telefonía. Entonces, de todos los servicios
ofrecidos por la empresa a los clientes, el de telefonía es soportado por ambas redes de
HFC y SDH.

En el caso de la red con HFC, para el ofrecimiento del servicio de telefonía se instalaron
en las cabeceras servidores de telefonía que convierten las interfaces V5.2 en señales de
RF que son transportable por cable coaxial, a través de la red con HFC. A estos
servidores se les denominan Host Digital Terminal (HDT) y para efectos prácticos se
considerarán que pueden soportar el ofrecimiento del servicio a un máximo de 500
líneas. Por otra parte, la instalación para un cliente incluye un dispositivo para poder
realizar la conversión de cable coaxial a pares de cobre para la conexión con los
teléfonos. A dicho dispositivo se le denomina Voice Port (VP) o puerto de voz. En el
siguiente gráfico se muestra un esbozo de cuál sería la red de telefonía sobre HFC de la
empresa:

Gráfico 2: Red HFC

Como se puede observar, los cables coaxiales con HFC sirven básicamente para el
transporte de la información, mientras que la central de conmutación recibe la
información por medio de interfaces V5.2. Para poder hacer efectivo el ofrecimiento del
servicio de telefonía sobre SDH, los medios cambian, y la red de transporte se sirve
directamente de las salidas de las interfaces V5.2, que a través de la red SDH se acercan
hasta las localidades de los clientes, en donde se conectan con dispositivos
multiplexores. Los multiplexores son los que se encargan de convertir a pares de cobre
los datos recibidos desde la red SDH, y desde ellos se despliegan redes de pares de
cobre que van finalmente hasta donde finalmente se encuentran los clientes ofreciendo
el servicio de telefonía. Se asume que un dispositivo multiplexor puede ofrecer el
servicio hasta un máximo de 256 líneas telefónicas. A continuación se muestra un
gráfico con la distribución y funcionamiento de la red SDH:

111
 Gráfico 3: Red SDH

La evolución de la red a lo largo de los años de operación ha conllevado a los

responsables de la misma a priorizar las altas de telefonía sobre la red SDH, dejando a
la red HFC dedicada principalmente al ofrecimiento de servicios de acceso a internet y
TV. En el gráfico a continuación se muestra la arquitectura de la red correspondiente al
servicio de telefonía sobre HFC del operador:

Gráfico 4: Red por zonas

La red está distribuida geográficamente en tres zonas diferenciadas denominadas las

zonas 1, 2 y 3. La cabecera HFC principal se encuentra situada en la zona 1, mientras
que las otras dos zonas disponen de cabeceras secundarias que únicamente incluyen
parte de los equipos de la cabecera principal de la zona 1. Para el servicio de telefonía,
la cabecera de la zona 1 incluye la central de conmutación que realiza la interconexión
con la red telefónica conmutada. Las cabeceras de las zonas 2 y 3 no disponen de una
central de conmutación, sino que las interfaces V5.2 que dan el servicio de telefonía a
los usuarios de estas zonas son transportadas por la red SDH hasta la central de
conmutación situada en la cabecera de la zona 1. La distribución inicial de servidores y
de clientes de telefonía sobre HFC es la siguiente:
• Zona 1: 7 equipos HDT ofreciendo servicio a 2864 líneas de telefonía
• Zona 2: 2 equipos HDT ofreciendo servicio a 384 líneas de telefonía
• Zona 3: 1 equipo HDT ofreciendo servicio a 123 líneas de telefonía
El operador en cuestión dispone de un total de 10 equipos HDT que ofrecen servicio a
un total de 3371 líneas de telefonía.

El proveedor de equipos de telecomunicaciones a la empresa operadora anuncia que

descatalogará la familia de productos para telefonía integrada HFC, por lo que el
operador ha decidido comenzar un proceso de migración de los clientes de telefonía
actualmente servidos por esta plataforma al a tecnología superpuesta por SDH, con el
objetivo de recuperar los equipos. El operador asumirá esta situación como una
oportunidad para la homogenización de la red de telefonía. A continuación se expone un

112
gráfico con el organigrama de los departamentos estructurados en el área de red del
operador:

Gráfico 5: Organigrama del área de red del operador

El área de red se divide en tres departamentos que son los siguientes:

• Departamento de ingeniería: Se divide por tecnologías, es el encargado del
diseño de la red, instalación, configuración y activación de los equipos, así como
de realizar seguimiento y control de sus ocupaciones para posteriores
ampliaciones y reconfiguraciones.
• Departamento de operaciones y mantenimiento: Se encarga de garantizar el
correcto funcionamiento de la red. Incluye un centro de control en donde se
monitorean las 24 horas todos los elementos de la red, un equipo de soporte con
técnicos expertos en cada una de las plataformas incluidas en la red, y los
equipos de mantenimiento que realizan actuaciones sobre los equipos de la red,
tanto preventivas como reactivas.
• Departamento de construcción: Es en encargado de todo lo relacionado con
obras civiles y con el acondicionamiento y mantenimiento de los locales de la
empresa.
Sobre estos departamentos y el área de comunicaciones de la empresa se conformará la
estructura del equipo de profesionales de la empresa que trabajarán en el proyecto de
migración de tecnologías.

113
CAPÍTULO 8: GRUPO DE PROCESOS DE INICIACIÓN

8.1 INTRODUCCIÓN:

Para estructurar la definición, justificación y planificación general del proyecto de

migración de tecnologías se ha tomado como referencia el libro del PMBOK, de
acuerdo al cual en el presente proyecto, la primera fase viene a ser la inicialización, en
la que se expone la documentación inicial del proyecto. Dicha documentación está
conformada por el acta del proyecto o Project Charter, que incluye la información sobre
los objetivos del proyecto, los patrocinadores que participarán, los recursos económicos
iniciales con los que se contarán, un análisis preliminar de las principales amenazas y
oportunidades que se puedan presentar, y tanto el personal que conformará al equipo de
trabajo del presente proyecto como también la elección del administrador a cargo del
mismo. Este documento incluye además una descripción sobre el trabajo a realizarse, las
fases en las que se subdividirá, así como un calendario con las fechas y duraciones
programadas de cada fase y del proyecto, y por último una relación con los entregables.
Cabe resaltar que a pesar que en el desarrollo de toda esta información de iniciación
haya participado el equipo de trabajo que se designó para el proyecto, tanto su revisión
como aprobación definitiva fueron realizados conjuntamente por el administrador del
proyecto y los patrocinadores respectivos.

8.2 ACTA DEL PROYECTO:

8.2.1 Definición:

El presente proyecto tiene como finalidad realizar la migración de los servicios de

telefonía con tecnología HFC hacia servicios de telefonía prestados a los clientes de la
empresa con tecnología SDH. La finalidad para lograr dicha migración es la de lograr
primero una reducción máxima de la cantidad y dispersión por la red de usuarios que
son servidos con la tecnología HFC. La reducción de la dispersión de los usuarios en la
red del operador será muy tomada en cuenta debido a que no se podrá proceder a retirar
ningún dispositivo de HFC mientras éste prestando servicio al menos a una cantidad
mínima de usuarios.

La iniciativa del proyecto surge debido a que la empresa proveedora de equipos para
HFC descatalogará dichos equipos a partir del día Lunes 7 de Marzo del 2011, lo cual
imposibilita futuros pedidos de equipos que utilicen esta misma tecnología por parte de
la empresa. Entonces se decidió que el servicio sea aplicado con otra tecnología, y los
equipos de HFC que sean retirados se podrán utilizar para el mantenimiento del resto de
equipos HFC que queden operantes en la red de la empresa. La iniciativa del proyecto
es considerada también por parte del departamento técnico de la empresa como una
oportunidad para comenzar a modernizar la red con una nueva tecnología.

8.2.2 Objetivos:

Con el presente proyecto de migración se pretende hacer una recuperación de los

equipos de comunicaciones que actualmente dan soporte a la red de telefonía con la
tecnología HFC y a los respectivos usuarios servidos, con la finalidad que dichos

114
equipos se puedan reutilizar posteriormente para brindar otros servicios además de
servir de mantenimiento a los equipos de su misma tecnología que aún permanezcan
operativos, reducir la dispersión de los usuarios no migrados a lo largo de la red, y
lograr una mayor homogenización de la red telefónica a una nueva tecnología como es
en este caso será la tecnología SDH. El objetivo principal entonces, será lograr la
retirada de un mínimo de tres equipos HDT de funcionamiento; para lograrlo,
previamente se deberán llegar a desinstalar por lo menos un 50% de los dispositivos
Voice Ports o VPs, manteniendo siempre la más baja dispersión geográfica posible de
usuarios a migrar por los motivos expuestos previamente. Para ello la red de la empresa
se dividirá en sectores, los cuales quedarán demarcados según las zonas de influencia de
los equipos HDT, y en caso no se pueda migrar algún sector por motivos de dispersión
de usuarios, se analizará otro sector de la red.

8.2.3 Personal:

Según lo acordado en la reunión de presentación de necesidades del proyecto de

migración, el personal de la empresa que se asignará al equipo de profesionales que
trabajarán juntos en el desarrollo del proyecto estará repartido en tres de los
departamentos de la empresa. Esta decisión se debe a que las necesidades del proyecto
abarcarán un trabajo conjunto que se podrá cubrir en su totalidad con el aporte de estos
tres departamentos que son los de Construcción, Ingeniería y Comunicaciones. Cada
departamento dispondrá de un coordinador, el cual tendrá a su cargo al personal de su
respectiva sección. El personal se distribuirá según se expone a continuación:
• Departamento de Construcción: Es el departamento que se encarga de la
subcontratación y supervisión de las empresas que trabajarán conjuntamente en
el proyecto realizando todas las actividades que involucren obras civiles
requeridas. El personal que lo conforma será el siguiente:
o Coordinador de construcción
o Técnicos de construcción
o Empresa subcontratada
• Departamento de Ingeniería: Es el departamento que abarca la realización de
todas las tareas técnicas y especializadas en las tecnologías de las que se sirve y
hace servir la empresa, como son la revisión, instalación, desinstalación,
configuración, mantenimiento de equipos de la red, entre otros. El equipo a
cargo de este departamento está conformado por:
o Coordinador de ingeniería
o Operadores de la red
o Técnicos de conmutación
o Técnicos de acceso
o Instaladores / Activadores de equipos
• Departamento de Comunicaciones: Se encarga de las comunicaciones internas y
externas de la empresa. Está para interactuar tanto con los clientes y personal
interno de la empresa, como con los patrocinadores y empresas subcontratadas y
proveedoras. Sus funciones son pedir datos, enviar información, ofrecer nuevos
servicios, hacer comunicados, gestionar los pagos del servicio, atender las
llamadas de los clientes, etc. Los miembros de este departamento serán:
o Coordinador de comunicaciones
o Administrativos de la red
o Gestores de clientes

115
Se ha decidido asignar como jefe a cargo del proyecto de migración de tecnologías al
coordinador del departamento de Ingeniería, debido a que la naturaleza del proyecto en
cuestión es principalmente técnica, y ha sido este departamento el que ha detectado la
necesidad del cambio en la red. Además de tratarse de una persona capacitada y con
mucha experiencia en el tema, conoce tanto la red de la empresa como sus necesidades
en este sentido, trabaja bien en equipo, y ha sido recomendado a la directiva por
personal con el que trabajó.

8.2.4 Organización:

Como ya se mencionó anteriormente, en el esquema organizado del equipo de trabajo

designado para el proyecto que se encargará de la ejecución de la migración, se
mantendrán los tres departamentos de la empresa que intervendrán en el desarrollo, y a
su vez se incluirán tres niveles de jerarquía, con lo que queda definida la estructura de
subdivisión organizacional u OBS (Organizational Breakdown Structure) del proyecto,
la cual será de la siguiente forma:

Gráfico 6: Estructura de subdivisión organizacional

Además del equipo que formará parte de la OBS del proyecto, también tendrán una
participación en el mismo los patrocinadores. En el caso del presente proyecto de
migración, no habrá patrocinadores externos debido a que el proyecto es de origen
interno de la empresa y no tendrá relación directa o mayor interés por parte de agentes u
organizaciones externas a la misma. Los patrocinadores del proyecto entonces, serán
exclusivamente miembros de la directiva de la empresa, los cuales asumirán la
responsabilidad de aprobación del proyecto, verificación de la asignación de tiempos y
recursos de la empresa, búsqueda de resultados que sean adecuados para los intereses de
la empresa, y responsabilidad en caso de contratiempos significativos por causas ajenas
a los dominios del proyecto.

8.2.5 Presupuesto:

116
El proyecto de migración de tecnologías en la red telefónica de la empresa se considera
dentro de las actuaciones de adecuación de la red, por lo que se decide que no es
necesario tener que efectuar ninguna asignación presupuestaria adicional para el
proyecto. El presupuesto inicial estimado para poder llevar a cabo el proyecto de
migración es de 67’191 €, en el que se incluirá aparte un monto de seguridad adicional
del 8% de la cantidad mencionada, que se pondrá a disposición del equipo del proyecto
en caso de que las estimaciones se hayan visto excedidas, siempre y cuando éstas sean
justificadas debidamente.

La cantidad de seguridad adicional del presupuesto fija que el monto total del
presupuesto del que podrá disponer la administración del proyecto sea de 72’566,28 €, y
en el caso de que los gastos del desarrollo del proyecto se terminen sobrepasando de
este margen total, el administrador del proyecto deberá realizar un informe dirigido
hacia los patrocinadores de la empresa explicando detalladamente todas las razones por
las cuales se sobrepasaron del monto estipulado, y cuánto presupuesto a más será
requerido para la finalización del trabajo. La decisión final de si se concederá un abono
extra de presupuesto o no, ya sea en su totalidad o parcialidad, se justificará por medio
de un estudio tanto del informe presentado como de la situación del proyecto, de la
empresa, y del entorno en el momento que ocurra.

En el presente proyecto, el presupuesto del que se dispone considera dos aspectos

diferentes en la fase de ejecución para la migración a la tecnología SDH: Una de las
partes se dirigirá para la evolución de la red ya existente, mientras que la otra cubre el
despliegue de un nuevo sector de la red. La parte de evolución, a diferencia del de
despliegue, no incluye trabajos relacionados al crecimiento de la red, sino únicamente
tareas como el reemplazo del cableado, el cambio en los equipos de comunicaciones, la
configuración de los mismos, entre otros. En la migración o adecuación de la red ya
existente, se incluyen tanto la migración directa como la migración con ampliación.
Ambos migraciones, tanto en la fase de prueba piloto como en la de migración del resto
de sectores de la red telefónica, tendrán un coste que ascenderá hasta los 24’730 €. Por
otra parte, en el despliegue de un nuevo sector de la red SDH, la asignación
presupuestaria fijada tiene un monto máximo previsto de 28’406 €. Cabe mencionar que
ambas cantidades no incluyen el margen del 8% de seguridad respectivo.

8.2.6 Riesgos:

La administración del proyecto se centrará en la gestión de riesgos como uno de los

ámbitos más importantes para controlar el correcto desarrollo del proyecto dentro de los
parámetros y criterios establecidos, evitar cualquier amenaza que pueda comprometerlo,
y poder aprovechar las oportunidades que se presenten. La gestión de los riesgos se
centrará para su funcionamiento en aspectos básicos como la comunicación, la
generación de documentación y revisión de documentación previa, y el estricto respeto
a las designaciones y reglas establecidas por la gestión del proyecto para la toma de
decisiones y actuación.

Los diferentes riesgos sobre los que se trabajen se clasificarán en base a los estándares
establecidos por el PMBOK, los cuales dividen a los riesgos según sus causas en las
siguientes categorías:
• Riesgos técnicos
• Riesgos externos

117
 • Riesgos organizacionales
• Riesgos de administración
En base a esta clasificación se desarrollará la estructura de subdivisión de los riesgos o
RBS (Risk Breakdown Structure), y en la que finalmente serán clasificados todos los
riesgos que se tomarán en cuenta por la gestión del proyecto.

Además de clasificar los riesgos en base a sus fuentes de origen, se clasificarán también
por niveles de prioridad para poder separar los riesgos que requieran de una respuesta
inmediata de la administración de los que únicamente serán monitoreados. Como
medida previa a la elaboración de las respuestas, se estudiará la aplicación de estrategias
de gestión de riesgos y sobre las cuales se propondrán luego las posibles respuestas. Los
riesgos serán gestionados de manera indiferente de que se traten de amenazas u
oportunidades. La gestión de riesgos incluirá también continuas revisiones y monitoreo
de los riesgos en función de sus causas y prioridades.

Los detalles sobre la clasificación, análisis, planificación y tratamiento de los riesgos

previstos se expondrán con mucha más profundidad en el apartado correspondiente a la
gestión de riesgos.

8.3 ALCANCE PRELIMINAR DEL PROYECTO:

8.3.1 Alcance:

Como ya se ha mencionado anteriormente, el presente proyecto de migración de

tecnologías tiene como propósito la recuperación de los dispositivos de telefonía de los
usuarios que son servidos a través de HFC para posteriormente poder proceder a la
desinstalación de estos equipos de la red. Se planea liberar un mínimo de tres o más
equipos HDT según sea posible, y para lograrlo es necesario recuperar como mínimo el
50% de dispositivos VP en un conjunto de usuarios que se encuentre lo más agrupado
posible geográficamente.

El tiempo de ejecución del proyecto ha sido delimitado por dos factores prioritarios que
intervienen de manera definitiva en el calendario de la planificación. Dichos factores
vienen a ser los plazos mínimos exigidos por el personal del departamento operativo
para poder realizar la migración de tecnologías con garantías teniendo en cuenta
aspectos tanto técnicos como burocráticos. Por otra parte están las fechas límite
comunicadas por la compañía proveedora de equipos de telecomunicaciones para el
descatalogado definitivo de los equipos de HFC.

8.3.2 Calendario:

Debido a los factores de restricción temporal expuestos en el apartado de alcance, se ha

determinado que el plazo para la realización de la migración de tecnologías en la red de
telefonía sea de 198 días, que serán distribuidos en tres fases principales:
• Fase 1: Análisis de la red
• Fase 2: Prueba piloto
• Fase 3: Migración de la red

118
Dichas fases han sido ordenadas cronológicamente y se exponen en el gráfico a
continuación, incluyendo datos del margen de tiempo adicional, con detalles de
duraciones, y sus respectivas fechas de inicio y fin:

Gráfico 7: Duración del proyecto por fases

El calendario de fechas previsto para el desarrollo del proyecto y sus respectivas fases
ha sido determinado de la siguiente manera:
• Inicio Fase 1: Lunes 3 de Mayo de 2010
• Fin Fase 1: Viernes 14 de Mayo de 2010
• Inicio Fase 2: Viernes 14 de Mayo de 2010
• Fin Fase 2: Miércoles 21 de Julio de 2010
• Inicio Fase 3: Miércoles 28 de Julio de 2010
• Fin Fase 3: Martes 1 de Febrero de 2011
• Límite del proyecto: Jueves 3 de Marzo del 2011

Al plazo fijado para el desarrollo del proyecto, como ya se mencionó, se ha previsto

agregar un tiempo de margen que será útil en caso de producirse demoras o
complicaciones en la ejecución. El plazo adicional máximo de tiempo que se fijó es del
10,4% de la duración total, por lo que el plazo máximo para la entrega de los resultados
se fija en 218 días útiles a partir de la fecha de inicio. Se desea que para la fecha de fin
del plazo estipulado, se tenga a la totalidad de usuarios que se sirven con la nueva
tecnología SDH recibiendo el servicio de manera correcta y estable.

8.3.3 Entregables:

La naturaleza del presente proyecto de migración a diferencia de otros, no es la de

fabricar y lanzar productos determinados hacia el mercado, o la realización de un
servicio dado a un cliente o grupo de clientes en concreto. Es una diferencia netamente
técnica, que se basa en la realización de cambios e incorporaciones internas en los

119
equipos de comunicaciones de la red de la empresa, siempre con el respectivo trabajo
previo y posterior que esta tarea conlleva. Teniendo en cuenta estas razones expuestas,
la lista de entregables que se prevén entregar tanto a lo largo del desarrollo del proyecto,
como cuando este finalice, son los siguientes:
• Informe de estado inicial de la red
• Informe de resultados de la prueba piloto
• Informe de resultados de la migración
• Listado de todos los usuarios con el nuevo servicio
• Informe de calidad del nuevo servicio a los usuarios
• Entrega de los equipos HFC desactivados
• Finalización dentro del tiempo y presupuesto máximos estipulados

Como ya ha sido mencionado en el apartado previo, lo que se desea comprobar para

poder dar el proyecto de migración por finalizado es que tanto con la serie de informes
técnicos entregados, como con las pruebas finales y los sondeos del nuevo servicio, se
pueda comprobar de una manera coherente y verificable que se han cumplido con los
objetivos propuestos en este proyecto.

120
CAPÍTULO 9: GRUPO DE PROCESOS DE
PLANIFICACIÓN

9.1 DEFINICIÓN DE LA ESTRUCTURA DE SUDIVISIÓN DEL TRABAJO:

9.1.1 Concepción del WBS:

Para el desarrollo de la estructura de subdivisión del trabajo o WBS para la realización

del proyecto de migración de tecnología, primeramente se concibió la manera en la que
se deseaba proceder a realizar las tareas a un alto nivel, luego se ordenaron todas éstas
en secuencia cronológica y por último se fue progresivamente bajando el nivel
(aumentando el detalle) de las tareas y separándolas hasta tener finalmente conocidas
todas las tareas, de manera que el WBS se adapte al 100% a las características de
ejecución del trabajo a realizar.

El proyecto de migración de tecnologías requerirá para comenzar, de todo un análisis a

fondo del estado de la red de la empresa en el que se incluirán un estudio del estado de
los principales dispositivos que la conforman, así como detalles de la distribución de los
mismos, números y estadísticas del tráfico en la red y tanto de su utilización como de su
rendimiento. Paralelamente con ello, se realizará un estudio minucioso de la inclusión
en la red de los dispositivos que soportan la nueva tecnología SDH, que contemple el
cambio que sufrirá la red en el tráfico, pruebas de rendimiento y la comparación
respecto al de los equipos que soportan tecnología HFC.

Otra tarea a realizar en el comienzo de la ejecución del proyecto, será la de listar a todos
los clientes del sector de la red que se vaya a sufrir el cambio de tecnología, contactarlos
y avisarles del cambio del servicio. En este momento es en el que se tratará el problema
que pueda suponer que algunos clientes no estén de acuerdo con el cambio, o que la
tarea de modificación de equipos en la residencia de los clientes no se pueda realizar por
diversos motivos.

Luego que los informes de las revisiones iniciales sean verificados y valorados, y sus
posibles problemas solucionados, se seleccionará un pequeño sector de la zona de la red
donde se desean hacer los cambios para hacer la migración a modo de prueba para ver
los problemas que puedan surgir y los resultados reales de los cambios realizados antes
de aplicarlos al resto de la zona designada de la red. Por razones de simplicidad, el
sector que se escoja para ejecutar dicha migración inicial no tendrá la necesidad de
realización de obras de construcción que puedan tener otros sectores, para poder centrar
los esfuerzos y resultados de esta primera operación en temas netamente técnicos y de
migración. Al finalizar dicha operación, todo el personal que haya participado en la
migración brindará su aporte para la realización de informes de resultados, los cuales
serán valorados por los jefes de los respectivos departamentos involucrados. En caso de
que el primer intento de migración haya sufrido problemas trascendentales que no
tengan una resolución clara o se decida que existen inconvenientes por los que ya no es
útil a la empresa seguir adelante con el proyecto, éste será el último momento dentro de
lo planificado para dar el aviso a la directiva de la empresa antes de finalmente decidir
si se continúa llevando a cabo el proyecto.

121
Una vez tomados en cuenta los informes de resultados de la primera migración, y si no
existen mayores contratiempos, se procederá a la ejecución de la migración en el resto
de la zona designada de la red de comunicaciones. Este proceso comenzará con una
planificación por sectores de la zona, teniendo en cuenta los resultados de la
comunicación y acuerdo con los clientes, las necesidades de obras civiles en la
ejecución, y las características y recomendaciones destacadas en los informes de la
primera migración. Luego de la planificación, se realizarán los pedidos de equipos que
funcionen con tecnología SDH que hagan falta para completar la necesidad de la
migración, mientras que se van preparando el resto de material y realizando las
peticiones de ejecución de obras civiles a los respectivos ayuntamientos. El aspecto
técnico de la realización de la migración contemplará la desconfiguración y retirado de
los equipos de HFC, seguidamente del transporte e instalación de los nuevos equipos de
SDH en su lugar, siendo estos luego configurados y las pruebas de funcionamiento
respectivas realizadas. Cabe destacar que el departamento técnico centrará parte de sus
esfuerzos en la máxima reducción posible del tiempo desde que se desconecten los
equipos de HFC hasta que estén en pleno funcionamiento los nuevos equipos de SDH,
dado que una mayor duración de este puede suponer problemas económicos para la
empresa, entre otros.

La migración de tecnologías se realizará de manera independiente entre sectores de la

red, debido a que algunos sectores pueden tener características diferentes en lo que
respecta a la distribución de los equipos, viabilidad del cambio por parte de los usuarios
consultados, requerimientos diferentes o nulos de obra civil, y por último, que es una
mejor manera de separar el trabajo, dado que en caso de ocurrir una demora o problema
en la migración, dichos inconvenientes no serán notados por la totalidad de los clientes
que reciban el cambio de servicio sino por un pequeño grupo, logrando así reducir la
percepción del impacto debido a problemas técnicos, de ocurrirse. Este factor hará que
el tiempo de ejecución de la migración no sea el mismo en cada sector, por las mismas
razones expuestas anteriormente, con lo cual el proyecto no se podrá dar por finalizado
hasta que se termine con el último de los sectores. Esto supondría la apertura de un
camino crítico en cuestiones temporales en función de la distribución de los sectores en
la red y sus características propias.

Al concluirse la migración en un sector dado, el grupo de técnicos y profesionales

asignados al mismo tendrán la obligación de entregar informes de resultados, en el que
se pondrán la descripción del procedimiento llevado a cabo, las incidencias surgidas a lo
largo del trabajo, así como finalmente los resultados a nivel técnico, de equipos, de la
red, y de los usuarios. Cuando se finalicen todos los sectores y se tengan todos los
informes respectivos revisados, se procederá a la redacción de un informe final en el
que se demuestre con pruebas realizadas en toda la red, de que está ya funcionando
correctamente y el servicio se brinda sin problemas a todos los usuarios migrados. Este
último informe con los objetivos logrados será entregado al gestor del proyecto, y una
vez sea revisado y aceptado, se pondrá a disposición de la directiva de la empresa para
que se haga la respectiva valoración, y posteriormente dar por concluido el proyecto de
migración de tecnologías.

9.1.2 Subdivisión principal:

122
Después de exponerse el procedimiento con el cual se planea llevar a cabo la ejecución
del proyecto, se ha decidido hacer una primera subdivisión del trabajo en tres partes
principales y sucesivas, que son descritas a continuación:
• Primera fase - Análisis de la red: En esta fase se realizarán todos los estudios
respectivos a las redes HFC y SDH, para poder tener información técnica sobre
cómo se hará para ejecutar posteriormente la migración en el sector de la prueba
piloto. Al mismo tiempo, se irán listando y contactando con los clientes para
informarles del cambio a realizar.
• Segunda fase - Prueba piloto: Teniendo muy en cuenta los resultados obtenidos
en la fase previa de análisis, se seleccionará un sector de la red que no suponga
mayores inconvenientes para realizar una migración a modo de prueba. Se
pretende ver cómo funciona el sector de la red migrado, así como los equipos
instalados y el servicio que reciben los usuarios migrados. De esta fase también
se generarán informes de los resultados obtenidos para que sean valorados antes
de proceder a la migración del resto de sectores.
• Tercera fase - Migración de la red: Una vez que se haya realizado la migración
con éxito en el sector de prueba se procederá a la migración de cada uno de los
otros sectores de la red de telefonía por separado, debido a las diferentes
características que cada uno presenta. Al finalizarse la migración se generarán
informes de resultados y objetivos cumplidos para que éstos sean revisados y el
proyecto se dé por finalizado.

A continuación se muestra una tabla con las tareas del primer nivel de subdivisión de la
estructura de subdivisión del trabajo para el presente proyecto:

Referencia Tarea
1 Migración de tecnologías en la red telefónica
1.1 Reunión de lanzamiento del proyecto
1.2 Primera fase: Análisis de la red
1.3 Segunda fase: Prueba piloto
1.4 Tercera fase: Migración de la red
1.5 Reunión de cierre del proyecto
Tabla 11: Subdivisión principal de actividades

En la tabla se muestran dos tareas más que son reuniones de lanzamiento y cierre del
proyecto. En la primera reunión se discutirán los detalles de planificación y puntos a
tener en cuenta antes de comenzar con la ejecución de la primera fase. La segunda
reunión es más de carácter evaluativo, en la que se analizarán los resultados generales
de todo el proyecto y verificar que se hayan completado los objetivos antes de dar el
cierre definitivo al proyecto.

9.1.3 Tipos de migración:

En función de las necesidades técnicas requeridas para la adecuación de los espacios

para albergar los dispositivos y el cableado, la capacidad y adaptación de la nueva red
para dar soporte a la nueva tecnología, y la instalación de los equipos, se han definido
tres maneras de migración diferentes de acuerdo a la siguiente lógica:

123
 Gráfico 8: Lógica para determinar el tipo de migración

Luego de conocer la lógica que se aplicará para realizar la migración de tecnologías en

cada sector, se hace un breve resumen de cómo es cada tipo de migración:
• Migración directa: Se produce cuando la nueva red tiene la capacidad suficiente
para poder dar soporte a las líneas migradas, manteniendo los umbrales de
ocupación recomendados en el diseño. Las tareas que comprende esta migración
se muestran en la siguiente tabla:

Tarea
Migración directa
Comunicación inicial con los clientes
Configuración de líneas provisionales SDH
Configuración de la central de conmutación
Configuración del acceso
Generación de scripts de migración
Generación de scripts de conmutación
Generación de scripts de acceso
Migración de líneas

124
 Desconfiguración de líneas provisionales
Desconfiguración de la central de conmutación
Desconfiguración del acceso
Comunicación final con los clientes
Tabla 12: Actividades de la migración directa

• Migración con ampliación: Se aplicará en caso que la nueva red no tenga la

capacidad requerida y sea preciso una ampliación de los equipos existentes para
conseguir el soporte de las líneas migradas con los umbrales de ocupación
planificados. Las tareas que comprende esta migración se muestran en la
siguiente tabla:

Tarea
Migración con ampliación
Ampliación de los equipos de acceso
Solicitud de permiso de actuación para instalación
Solicitud de material
Pedido de reposición de material
Instalación y activación de equipos adicionales
Comunicación inicial con los clientes
Configuración de líneas provisionales SDH
Configuración de la central de conmutación
Configuración del acceso
Generación de scripts de migración
Generación de scripts de conmutación
Generación de scripts de acceso
Migración de líneas
Desconfiguración de líneas provisionales
Desconfiguración de la central de conmutación
Desconfiguración del acceso
Comunicación final con los clientes
Tabla 13: Actividades de la migración con ampliación

• Migración con construcción: Cuando no existe una estructura capaz de soportar

a la nueva red SDH y se deben instalar nuevos equipos multiplexores y realizar
las obras de construcción respectivas para su adecuación. Las tareas que
comprende esta migración se muestran en la siguiente tabla:

Tarea
Migración con construcción
Construcción de la red
Elaboración del proyecto constructivo
Solicitud del permiso de construcción externo
Solicitud de material

125
 Pedido de material
Ejecución de la obra civil
Instalación de equipos adicionales
Solicitud de activación de equipos
Activación de equipos adicionales
Comunicación inicial con los clientes
Configuración de líneas provisionales SDH
Configuración de la central de conmutación
Configuración del acceso
Generación de scripts de migración
Generación de scripts de conmutación
Generación de scripts de acceso
Migración de líneas
Desconfiguración de líneas provisionales
Desconfiguración de la central de conmutación
Desconfiguración del acceso
Comunicación final con los clientes
Tabla 14: Actividades de la migración con construcción

Nótese el hecho que las migraciones con ampliación y construcción no difieren con la
migración directa en más que en una primera tarea adicional, ya sea justamente la de
ampliación o construcción de la red en el sector respectivamente. El resto de las tareas a
realizar son exactamente iguales, lo que quiere decir que en términos de duración y
recursos, y salvo contratiempos, las migraciones con ampliación y construcción
excederán a la migración directa en lo que requiera la primera tarea adicional que se
mencionó previamente. Éste podrá ser un factor a tener en cuenta a la hora de calcular el
tiempo que tardará en desarrollarse el proyecto y el presupuesto que se invertirá en la
fase de ejecución total en función de sectores.

9.1.4 Subdivisiones secundarias:

Una vez que se han definido las fases principales del desarrollo del proyecto, se lleva a
cabo la definición de todas las tareas secundarias que van a conformar cada una de las
tres fases, desglosando cada tarea hasta el nivel más óptimo e incluyendo tanto los
trabajos a realizar, como los tipos de migraciones que se aplicarán en caso de aplicarse,
y siendo las listas de tareas de estos últimos tipos expuestas en el apartado anterior.
• Primera fase: En la primera fase del desarrollo, las tareas que hay que realizar
son revisiones técnicas, tareas de gestión de clientes, generación de reportes e
informes, y de índole similar, por lo que en esta primera fase no se requerirá más
que un nivel de subdivisión en las tareas para poder realizarlas y controlarlas sin
problemas. El listado definitivo de tareas que conformen la primera fase quedará
de la siguiente manera:

Referencia Tarea
1.2 Primera fase: Análisis de la red
1.2.1 Listado de clientes con HFC

126
 1.2.2 Análisis de la red HFC
1.2.3 Análisis de la red SDH
1.2.4 Análisis de la central de conmutación
1.2.5 Informe de estado inicial
1.2.6 Definición de la prueba piloto
Tabla 15: Actividades de la primera fase

• Segunda fase: La siguiente fase comprende acciones más complejas que la fase
anterior, debido a que ya se pasa a ejecutar la migración de todo un sector de la
red, y por ello, en esta fase habrá más de un nivel de subdivisión en las tareas.
En esta fase no se incluye la migración con construcción porque ya se mencionó
que por simplicidad para facilitar la prueba piloto, se escogerá un sector que no
lo requiera para realizar dicha prueba. Lo que no se descarta es que el sector
pueda tener partes que requieran de ampliación, por lo que se incluyen tanto la
migración directa como con ampliación entre las tareas. En esta fase también se
incluyen tareas de análisis de resultados y generación de informes como
consecuencia de la realización de la migración en el sector. A continuación se
propone la lista de tareas designadas para esta fase:

Referencia Tarea
1.3 Segunda fase: Prueba piloto
1.3.1 Reunión de lanzamiento de la prueba piloto
1.3.2 Migración directa
1.3.3 Migración con ampliación
1.3.4 Análisis de resultados de la red
1.3.5 Análisis de resultados de los clientes
1.3.6 Generación del informe de resultados
1.3.7 Reunión de cierre de la prueba piloto
Tabla 16: Actividades de la segunda fase

• Tercera fase: La tercera fase es la más larga, compleja e importante de las tres
fases del desarrollo del proyecto. Si bien es cierto que la lista de tareas que la
comprende es inicialmente muy similar a las de la segunda fase, en la tercera
fase, la migración no se aplica únicamente a un sector sino a todo el resto de
sectores que comprenden la zona de la red en donde se aplicarán los cambios de
tecnología. Además, comprende también la migración con construcción, que es
una de las tareas que más puede llegar a tardar hasta su finalización y consumir
recursos en el proyecto. Evidentemente en esta última fase también habrá más de
un nivel de subdivisión en las tareas que la conformen. Del mismo modo que en
la fase anterior, luego de ejecutarse las tareas de migración, como consecuencia
son incluidas tareas de análisis de resultados y generación de informes. Con todo
lo expuesto previamente, la lista de tareas de la que consta la tercera fase será
como se presenta a continuación:

Referencia Tarea
1.4 Tercera fase: Migración de la red
1.4.1 Reunión de lanzamiento del resto de la red

127
 1.4.2 Migración directa
1.4.3 Migración con ampliación
1.4.4 Migración con construcción
1.4.5 Análisis de los resultados de la red
1.4.6 Análisis de los resultados de los clientes
1.4.7 Generación del informe de resultados
Tabla 17: Actividades de la tercera fase

En total, el proyecto de migración de tecnologías tendrá una estructura de subdivisión

de trabajo dividida en tres fases principales, y constará con una cantidad de tareas
terminales que pueden ir desde 35 hasta 78 en función de las características de los
sectores en donde se aplicará la migración. Constará también con una jerarquía de hasta
cuatro niveles de subdivisión para poder asegurar una cantidad realizable de trabajo por
tarea, en un tiempo prudente, para el equipo y recursos asignados por tarea. Al
elaborarse la estructura de subdivisión de trabajo para el proyecto, se ha asegurado que
para cada tarea que contenga subdivisiones, la suma del trabajo de dichas sub-tareas
represente el 100% de la tarea original, para cualquier nivel de la jerarquía. Se ha
asegurado también que dicha estructura represente de manera secuencial, ordenada y
transparente todo el trabajo que se describió en el apartado de concepción del WBS para
que no haya errores, ni diferencias, ni carencias al revisar y comparar los resultados del
proyecto ejecutado en función de dicho WBS, respecto a los objetivos iniciales.

9.2 GESTIÓN DE RECURSOS Y TIEMPO EN EL PROYECTO:

Una vez determinada la estructura de subdivisión del trabajo, en la que se han listado,
definido y estructurado de manera detallada todas las actividades a realizar en el
proyecto, se desea planificar el tema de los tiempos en la ejecución del proyecto para
poder tener información precisa sobre las duraciones de las actividades, si habrá o no
cadena crítica y cuál sería en caso de haber, de qué actividades depende cada actividad y
qué otras actividades dependen de la misma. La importancia de este análisis radica en
saber la duración del proyecto y compararla respecto al plazo de tiempo del que se
dispone, saber qué actividades son las más cruciales, cuales consumen más recursos, y
cuales ralentizan la ejecución para ver si es posible acortar sus duraciones o acomodar el
esquema de sucesión de actividades para lograr un término de ejecución menor.

9.2.1 Listado de recursos:

Para un correcto análisis de la distribución del tiempo entre las actividades de las que
comprende el proyecto, primero se debe de realizar un análisis de los recursos a utilizar
por el proyecto y asignarlos a las tareas para luego poder extraer tanto la duración como
el coste de las mismas. En la siguiente tabla se muestra la RBS (Resource Breakdown
Structure) o estructura de subdivisión de los recursos disponibles, así como el coste que
supone la utilización de cada uno por hora, y la cantidad de cada elemento de la que se
dispone (mostrada entre paréntesis al final del nombre en caso de ser más de uno):

Referencia Recurso Costo Horas extra

Departamento de construcción
C-Const Coordinador de construcción 40 €/hora 50 €/hora

128
 T-Const Técnico de construcción (2) 20 €/hora 25 €/hora
Contr-C Contratista de construcción 50 €/hora 50 €/hora
Departamento de ingeniería
C-Ing Coordinador de ingeniería 40 €/hora 50 €/hora
Op-R Operador de la red (2) 20 €/hora 30 €/hora
T-Conm Técnico de conmutación (2) 20 €/hora 25 €/hora
T-Acc Técnico de acceso (2) 20 €/hora 30 €/hora
Inst-Act Instalador/Activador de equipos (4) 15 €/hora 25 €/hora
Departamento de comunicaciones
C-Com Coordinador de comunicaciones 40 €/hora 50 €/hora
Adm-R Administrativo de la red (2) 15 €/hora 25 €/hora
G-Cli Gestor de clientes (2) 15 €/hora 20 €/hora
Tabla 18: Estructura de subdivisión de los recursos

En el caso del contratista de construcción, se trata de una empresa subcontratada para

realizar las labores de obra civil requeridas, que serán conjuntamente coordinadas por el
coordinador de construcción y acompañadas en las labores por los técnicos del
departamento. Las horas extra se aplican a partir de la novena hora trabajada en un día.

9.2.2 Asignación de recursos a las actividades principales:

Entre las actividades del primer nivel de subdivisión, las únicas actividades terminales
vienen a ser las reuniones de lanzamiento y cierre del proyecto, y en ambas se han
designado a los coordinadores de los tres departamentos, dado que entre ellos
representan a todos los departamentos involucrados y son los responsables de ponerse
de acuerdo en los detalles generales a llevar a cabo del proyecto y comunicar cada uno
al personal de su respectivo departamento las tareas a realizar y demás indicaciones. La
asignación de recursos al primer nivel entonces, queda de la siguiente manera:

ID Tarea Recursos
1 Migración de tecnologías en una red telefónica
2 Reunión de lanzamiento del proyecto C-Const; C-Ing; C-Com
3 Primera fase: Análisis de la red
10 Segunda fase: Prueba piloto
47 Tercera fase: Migración de la red
105 Reunión de cierre del proyecto C-Const; C-Ing; C-Com
Tabla 19: Recursos para las actividades principales

Los recursos de las tres fases principales no se muestran porque éstas tienen actividades
con subdivisión de tareas, y sus detalles se mostrarán luego uno a uno con detalle.

9.2.3 Asignación de recursos por tipos de migración:

Luego de una evaluación a detalle por parte de los coordinadores y algunos técnicos y
expertos con experiencia previa en la materia, se han realizado las asignaciones de
recursos a cada uno de los tres tipos de procesos de migración a realizar. Las
asignaciones por tipos de migración son:

129
• Migración directa: Dado a que se trata de un proceso mayoritariamente técnico,
la mayor parte de los recursos asignados provienen del departamento de
ingeniería, en las que los técnicos son los encargados de las actividades de
configuración y programación, mientras que la migración propiamente dicha es
responsabilidad del instalador/activador, siendo ayudado por el operador de la
red al momento de realizar las primeras pruebas justo después de instalar los
equipos (es por ello que su participación se reduce al 25% de la actividad). Las
actividades de comunicación con los clientes para avisar del inicio y final de las
actividades, así como sondear la apreciación de los mismos sobre el nuevo
servicio y otras anotaciones, serán designadas a los gestores de clientes. La
presentación de las tareas con sus respectivos recursos es la siguiente:

ID Tarea Recursos
A Migración directa
B Comunicación inicial con los clientes G-Cli
C Configuración de líneas provisionales SDH
D Configuración de la central de conmutación T-Conm
E Configuración del acceso T-Acc
F Generación de scripts de migración
G Generación de scripts de conmutación T-Conm
H Generación de scripts de acceso T-Acc
I Migración de líneas Inst-Act; Op-R(25%)
J Desconfiguración de líneas provisionales
K Desconfiguración de la central de conmutación T-Conm
L Desconfiguración del acceso T-Acc
M Comunicación final con los clientes G-Cli
Tabla 20: Recursos para la migración directa

• Migración con ampliación: El proceso de ampliación de los equipos de acceso es

principalmente la diferencia entre este tipo de migración y la directa, en la que
todas las actividades de carácter tramitativo tales como pedidos de materiales y
permisos se realizan al comienzo por el administrativo de la red, y luego la
instalación y activación de los equipos por el instalador/activador con la ayuda
parcial del operador de la red en los momentos de realización de pruebas. Las
asignaciones de recursos en las actividades de la migración con ampliación son
de la siguiente manera:

ID Tarea Recursos
A Migración con ampliación
B Ampliación de los equipos de acceso
C Solicitud de permiso de actuación para instalación Adm-R
D Solicitud de material Adm-R
E Pedido de reposición de material Adm-R
F Instalación y activación de equipos adicionales Inst-Act; Op-R(25%)
G Comunicación inicial con los clientes G-Cli
H Configuración de líneas provisionales SDH

130
 I Configuración de la central de conmutación T-Conm
J Configuración del acceso T-Acc
K Generación de scripts de migración
L Generación de scripts de conmutación T-Conm
M Generación de scripts de acceso T-Acc
N Migración de líneas Inst-Act; Op-R(25%)
Ñ Desconfiguración de líneas provisionales
O Desconfiguración de la central de conmutación T-Conm
P Desconfiguración del acceso T-Acc
Q Comunicación final con los clientes G-Cli
Tabla 21: Recursos para la migración con ampliación

• Migración con construcción: En este caso el proceso que marca la diferencia con
la migración directa es el de construcción de la red, en el cual el proyecto
constructivo será elaborado por el técnico de construcción luego de visitar la
zona en donde se realizarán las obras. La ejecución de la obra civil estará a cargo
del contratista de construcción y el técnico de construcción, además de contar
con la supervisión inicial y final del coordinador de construcción para dar las
pautas a seguir en la obra y revisar los resultados. De la misma manera que en la
migración con ampliación, el administrativo de la red se encargará de las tareas
se gestión de pedidos y permisos necesarios para llevar a cabo las obras, obtener
los materiales y activar los equipos adicionales. Los recursos que se utilizarán en
la migración con construcción son los siguientes:

ID Tarea Recursos
A Migración con construcción
B Construcción de la red
C Elaboración del proyecto constructivo T-Const
D Solicitud del permiso de construcción externo Adm-R
E Solicitud de material Adm-R
F Pedido de material Adm-R
G Ejecución de la obra civil Contr-C; T-Const; C-Const(20%)
H Instalación de equipos adicionales Inst-Act; Op-R(25%)
I Solicitud de activación de equipos Adm-R
J Activación de equipos adicionales Inst-Act; Op-R
K Comunicación inicial con los clientes G-Cli
L Configuración de líneas provisionales SDH
M Configuración de la central de conmutación T-Conm
N Configuración del acceso T-Acc
Ñ Generación de scripts de migración
O Generación de scripts de conmutación T-Conm
P Generación de scripts de acceso T-Acc
Q Migración de líneas Inst-Act; Op-R(25%)
R Desconfiguración de líneas provisionales
S Desconfiguración de la central de conmutación T-Conm

131
 T Desconfiguración del acceso T-Acc
U Comunicación final con los clientes G-Cli
Tabla 22: Recursos para la migración con construcción

Básicamente a partir de las tareas G y K de las migraciones con ampliación y

construcción respectivamente, el resto de tareas son iguales a la migración directa, por
lo que la diferencia en tiempos y recursos en estos tipos de migración se da en las tareas
previas, y ello influirá al momento de analizar el camino crítico.

9.2.4 Asignación de recursos a las actividades secundarias:

Después de conocer los recursos a emplear en las actividades por tipos de migración, se
puede terminar de desglosar las actividades por fases para asignarles los recursos que
éstas requieran.
• Primera fase: En la primera parte del desarrollo del proyecto, las principales
tareas técnicas de análisis de las redes y de la central se realizarán entre los
técnicos acceso y conmutación, mientras que en el listado de los clientes con
HFC participará el gestor de clientes. Los técnicos también realizarán un
informe del estado inicial de las redes con los resultados de sus análisis que
luego se utilizarán para el diseño de la prueba piloto por parte de los tres
coordinadores de los departamentos involucrados. La asignación de recursos en
la primera fase se presenta a continuación:

ID Tarea Recursos
3 Primera fase: Análisis de la red
4 Listado de clientes con HFC G-Cli
5 Análisis de la red HFC T-Acc
6 Análisis de la red SDH T-Acc
7 Análisis de la central de conmutación T-Conm
8 Informe de estado inicial T-Acc; T-Conm
9 Definición de la prueba piloto C-Const; C-Ing; C-Com
Tabla 23: Recursos para la primera fase

• Segunda fase: La fase de la prueba piloto comienza con una reunión de

lanzamiento en la que participarán los coordinadores de los departamentos de
ingeniería y comunicaciones, así como los técnicos de conmutación y acceso y
el gestor de clientes, para discutir y organizar los detalles para la ejecución de
las migraciones. Las migraciones a ejecutar tendrán las asignaciones de recursos
expuestas en el apartado anterior, y luego los análisis de los resultados tanto a
nivel técnico como de servicio se realizarán por los técnicos de acceso y
conmutación, y el gestor de clientes, los cuales también prepararán los informes
con los resultados y finalmente se revisarán por los coordinadores involucrados
al final de la fase en la reunión de cierre. Los recursos asignados a las tareas de
la prueba piloto son:

ID Tarea Recursos
10 Segunda fase: Prueba piloto
11 Reunión de lanzamiento de la prueba piloto C-Ing; C-Com; T-Acc; T-Conm; G-Cli

132
 12 Migración directa
25 Migración con ampliación
43 Análisis de resultados de la red T-Acc; T-Conm
44 Análisis de resultados de los clientes G-Cli
45 Generación del informe de resultados T-Acc; T-Conm; G-Cli
46 Reunión de cierre de la prueba piloto C-Com; C-Ing
Tabla 24: Recursos para la segunda fase

• Tercera fase: Debido a las similitudes en la distribución de actividades entre la

segunda y tercera fase, la distribución de recursos será también parecida. En el
caso de la reunión de lanzamiento, será ahora presidida por los tres
coordinadores debido a que a diferencia de la fase anterior, ahora los tres
departamentos participarán activamente de la migración. Luego de la realización
de las sucesivas migraciones viene el análisis de los resultados por parte de los
técnicos de conmutación y acceso, y el gestor de clientes, seguidamente de la
generación de informes a partir de los resultados anteriores. La fase de
migración no tiene una última actividad de reunión de cierre como en la prueba
piloto porque la reunión que se produzca para analizar los resultados de las
migraciones se considera como una actividad de primer nivel. La lista con los
recursos para la tercera fase se presenta a continuación:

ID Tarea Recursos
47 Tercera fase: Migración de la red
48 Reunión de lanzamiento del resto de la red C-Const; C-Ing; C-Com
49 Migración directa
62 Migración con ampliación
80 Migración con construcción
102 Análisis de los resultados de la red T-Acc; T-Conm
103 Análisis de los resultados de los clientes G-Cli
104 Generación del informe de resultados T-Acc; T-Conm; G-Cli
Tabla 25: Recursos para la tercera fase

Es importante hacer mención de que en la segunda y tercera fase las migraciones se

ejecutan de forma paralela, y eso puede llevar a pensar que habrá cruces de utilización
de recursos en algún punto, pero ya se mencionó anteriormente que en el caso de estos
recursos ya se saben cuáles son y se disponen en más de una unidad.

9.2.5 Secuenciado y duración de las actividades principales:

En este apartado se expondrá y explicará el esquema de secuenciado de todas las

actividades del proyecto, así como la duración de cada uno de los procesos, y la cadena
crítica encontrada en caso de existir. En el análisis para determinar el secuenciado de las
actividades del proyecto, el tipo de relación que se utilizará entre actividades vinculadas
será únicamente el ‘Finish-to-start’ o finalizar para empezar, debido a que en ningún
caso se ha visto la necesidad de aplicar otro tipo de relación. Cabe mencionar además
que las duraciones presentadas a continuación no toman en cuenta el factor de tiempo
adicional que se mencionó en el capítulo de iniciación del proyecto, debido a que este

133
tiempo adicional es un margen que se tomará como un acumulado de todos los atrasos
que se produzcan en las actividades, por lo que se tendrá en cuenta como un porcentaje
de tiempo respecto a la duración de todo el proyecto al final del mismo y no respecto a
cada actividad por separado. La tabla con la lista de secuencia y duración de actividades
del primer nivel de la estructura de subdivisión es la siguiente:

ID Tarea Predecesoras Duración

1 Migración de tecnologías en una red telefónica 197,5 días
2 Reunión de lanzamiento del proyecto 5 horas
3 Primera fase: Análisis de la red 8,63 días
10 Segunda fase: Prueba piloto 48,13 días
47 Tercera fase: Migración de la red 134,13 días
105 Reunión de cierre del proyecto 104 1 día
Tabla 26: Secuenciado y duraciones de las actividades principales

Algunos de los tiempos mostrados figuran con decimales, debido a que las duraciones
de las actividades que contienen sub-tareas (listadas en negrita y con fondo gris) son
directamente el resultado de la suma de las duraciones de todas sub-tareas de las que
consta.

La primera fase del proyecto tendrá una duración total aproximada de 9 días, mientras
que las de la segunda y tercera fases serán de 49 y 135 días respectivamente, con lo que
la duración total del proyecto rondará los 198 días. La primera actividad de reunión de
lanzamiento será únicamente de 5 horas debido a que las pautas y puntos importantes
del desarrollo del proyecto ya se han discutido en la etapa de planificación, con lo cual
esta reunión tendrá únicamente la finalidad de discutir todos los detalles del proyecto
previos a la ejecución. La reunión de finalización del proyecto durará un día entero
debido a que se tendrán que analizar todos los informes generados sobre los resultados
de la migración tanto en cada sector como en la red en global.

9.2.6 Secuenciado y duración de las actividades por tipos de migración:

En el apartado de estructura de subdivisión del trabajo se comentó que la migración a

efectuar en los diferentes sectores de la red de comunicaciones sería de hasta tres
maneras diferentes, en función de las características del sector tanto a nivel de red como
de infraestructura. La diferencia de esas maneras de migración no únicamente radica en
algunas tareas adicionales que puedan tener al comienzo, sino en la diferencia de
duración que pueda haber entre unas y otras, y las secuencias de tareas de las que
depende cada una. Entonces, el secuenciado y duración de actividades según el tipo de
migración es presentado a continuación:
• Migración directa: Es un proceso que tiene una duración media aproximada de
20 días para su ejecución. Paralelamente con la comunicación a los clientes de
los cambios a realizar por parte de la empresa, se llevan a cabo las primeras
actividades de configuración, mientras que para finalizarlas se debe esperar a
que finalice la comunicación. De la misma manera empiezan las actividades de
generación de scripts, pero con la diferencia que para acabar necesitan antes que
finalicen las actividades previas de configuración. Luego viene la migración de
líneas, que es el proceso más largo, al durar 9 días y estar supeditado a que
previamente finalicen las taras de configuración de líneas provisionales y
134
 generación de scripts que le preceden. Una vez concluida la migración de las
líneas en el sector, se pasará paralelamente a las actividades de desconfiguración
de líneas provisionales y comunicación final con los clientes para notificarles de
los cambios realizados. La tabla de tareas quedaría entonces conformada de la
siguiente manera:

ID Tarea Predecesoras Duración

A Migración directa 16,63 días
B Comunicación inicial con los clientes X* 1,5 días
C Configuración de líneas provisionales SDH 1,13 días
D Configuración de la central de conmutación X* 1 hora
E Configuración del acceso B 1 día
F Generación de scripts de migración 1,88 días
G Generación de scripts de conmutación B 1 hora
H Generación de scripts de acceso E 7 horas
I Migración de líneas C+1 sem; G; H 9 días
J Desconfiguración de líneas provisionales 0,25 días
K Desconfiguración de la central de conmutación I 2 horas
L Desconfiguración del acceso I 2 horas
M Comunicación final con los clientes I 1,5 días
Tabla 27: Secuenciado y duraciones de la migración directa
(*Reunión de lanzamiento de la migración)

• Migración con ampliación: Previamente a las tareas de la migración directa, las

actividades en la migración con ampliación incorporan en su lista un conjunto de
tareas propias que son la de ampliación de equipos, en las cuales se realizan los
pedidos de los materiales necesarios y el permiso de actuación antes de de
instalar y activar los equipos de ampliación. Este proceso tardará cerca de 14
días, luego de los cuales la lista de actividades a seguir es muy similar que la de
la migración directa no sólo en distribución de actividades sino también similar
en secuenciado y duración. En este primer proceso adicional de ampliación
además, existe la dependencia de una actividad anterior que es una reunión de
lanzamiento previa a la ejecución de la migración con ampliación. En
comparación con la migración directa, la duración de la ejecución de la
migración con ampliación tardará unos 23 días más. La tabla con las actividades
y detalles de secuencia y duración se pone a continuación:

ID Tarea Predecesoras Duración

A Migración con ampliación 39,13 días
B Ampliación de los equipos de acceso 18,13 días
C Solicitud de permiso de actuación para instalación X* 5 horas
D Solicitud de material X*; C 5 horas
E Pedido de reposición de material D 2 horas
F Instalación y activación de equipos adicionales C+1 sem; D+2 días 12,5 días
G Comunicación inicial con los clientes F 1,5 días
H Configuración de líneas provisionales SDH 3 días

135
I Configuración de la central de conmutación F 2 días
J Configuración del acceso I 1 día
K Generación de scripts de migración 1,75 días
L Generación de scripts de conmutación I 5 horas
M Generación de scripts de acceso J 6 horas
N Migración de líneas G+1 sem; L; M 13 días
Ñ Desconfiguración de líneas provisionales 0,25 días
O Desconfiguración de la central de conmutación N 2 horas
P Desconfiguración del acceso N 2 horas
Q Comunicación final con los clientes N 1,5 días
Tabla 28: Secuenciado y duraciones de la migración con ampliación
(*Reunión de lanzamiento de la migración)

• Migración con construcción: En la migración con construcción, la lista de tareas

es casi la misma que la migración directa, con la excepción de un proceso
adicional que se realiza en el comienzo de la misma. Este proceso tiene que ver
con la construcción de infraestructura previa a la realización de la migración, y
es el que hace que la migración con construcción sea el tipo de migración que
más tarde en ejecutarse de los tres. El proceso de construcción empieza por la
elaboración del proyecto constructivo en el que se diseña y planifica las obras de
construcción en función de los equipos a instalar y las diversas necesidades tanto
técnicas como administrativas requeridas. Una vez planificado, se procede a la
solicitud de materiales y la tramitación del permiso de construcción, los cuales
dependen de factores externos a la empresa y son los que más ralentizan la
ejecución de esta parte de la migración. Luego se procede a la ejecución de obra
civil y posteriormente a la instalación y activación de los equipos. Las obras y la
instalación también abarcan una cantidad significativa del tiempo de la
migración. En total la migración con construcción está planificada para durar
unos 124 días, excediendo a la directa en 107 días, y con ampliación en 84 días,
por lo que es muy probable que la migración con construcción se considere
como parte de la cadena crítica del proyecto. El secuenciado y duración de las
tareas es el siguiente:

ID Tarea Predecesoras Duración

A Migración con construcción 123,63 días
B Construcción de la red 96,63 días
C Elaboración del proyecto constructivo X* 3 días
D Solicitud del permiso de construcción externo C 4 horas
E Solicitud de material C; D 4 horas
F Pedido de material E 3 horas
G Ejecución de la obra civil D+1,5 meses 1,7 meses
H Instalación de equipos adicionales G; E+1 mes 1 mes
I Solicitud de activación de equipos H 4 horas
J Activación de equipos adicionales I+8 días 5 horas
K Comunicación inicial con los clientes J 1,5 días
L Configuración de líneas provisionales SDH 2,13 días

136
 M Configuración de la central de conmutación J 1,5 días
N Configuración del acceso M 5 horas
Ñ Generación de scripts de migración 0,81 días
O Generación de scripts de conmutación M 3 horas
P Generación de scripts de acceso N 1,5 horas
Q Migración de líneas K+1 sem; O; P 3,8 sem
R Desconfiguración de líneas provisionales 0,25 días
S Desconfiguración de la central de conmutación Q 2 horas
T Desconfiguración del acceso Q 2 horas
U Comunicación final con los clientes Q 1,5 días
Tabla 29: Secuenciado y duraciones de la migración con construcción
(*Reunión de lanzamiento de la migración)

Cada tipo de migración no es necesariamente exclusiva de un sector en concreto de la

red, debido a que puede darse el caso de sectores que necesiten de más de un tipo de
migración debido a que sus características de capacidad y distribución de equipos no
son uniformes en toda su extensión, y por lo tanto se deban aplicar diferentes tipos de
migración según la zona del sector que lo requiera. En el caso del sector en donde se
realizará la prueba piloto, si bien es cierto que se descartó un sector con necesidad de
construcción, se ha escogido un sector que requiera de migración directa y con
ampliación, para que los resultados de la ejecución sean más completos a nivel técnico y
sirvan como ejemplo para los demás sectores que lo puedan necesitar. Para todos los
casos de sectores que requieran de más de un tipo de migración, las ejecuciones de estas
migraciones en el sector en cuestión se realizarán de forma paralela.

Nótese que en este apartado de secuenciado y duración de actividades por tipos de

migración, los IDs asignados a las tareas han sido letras y no números. Esto se debe a
que los números indican directamente el ID de la tarea en la estructura de subdivisión, y
si se aplica un mismo tipo de migración en más de una ocasión, una misma tarea puede
tener dos o más números de ID diferentes. Para no generar confusión, se asignaron
letras de modo genérico, con el único propósito de que se entiendan las reglas de
secuenciado sin confundirse con los IDs que estas actividades puedan tener en la
estructura de subdivisión del trabajo real del proyecto.

9.2.7 Secuenciado y duración de las actividades secundarias:

Al ser definidas las secuencias y duraciones de las tareas de las migraciones por tipos,
ya se puede completar el mismo para las actividades de los niveles secundarios de la
estructura de subdivisión del trabajo. Se mostrarán las tablas con las asignaciones por
fases, pero no se mostrarán los detalles de actividades en los tipos de migración debido
a que estos ya han sido expuestos en el apartado anterior.
• Primera fase: Como se comentó en el apartado de actividades principales, la fase
de análisis de la red comienza cuando acabe el primer proceso del proyecto, de
reunión de lanzamiento del proyecto, debido a que todas sus actividades
dependen de alguna forma en que ésta acabe previamente. Es la fase que tiene
menor duración de las tres y es de crucial importancia para la realización de la
siguiente fase de prueba piloto. La tabla con los detalles de secuencia y duración
entre las actividades se muestra a continuación:

137
 ID Tarea Predecesoras Duración
3 Primera fase: Análisis de la red 8,63 días
4 Listado de clientes con HFC 2 5 horas
5 Análisis de la red HFC 4 4 días
6 Análisis de la red SDH 4; 5 2 días
7 Análisis de la central de conmutación 4 2 días
8 Informe de estado inicial 6; 7 1 día
9 Definición de la prueba piloto 8 1 día
Tabla 30: Secuenciado y duraciones de la primera fase

• Segunda fase: La prueba piloto es un proceso que tiene una duración estimada
en 49 días, y se realiza en un sector que incluirá tanto migración directa como
con ampliación por motivos ya expuestos en el apartado anterior. Luego de
revisados y estudiados los resultados de la primera fase se llevará a cabo la
reunión de lanzamiento de la prueba piloto, que tardará alrededor de un día y de
la que dependen las migraciones para comenzar a llevarse a cabo. Ambas
migraciones se ejecutarán en paralelo, cada una de la manera en que se mostró
en sus respectivas tablas, pero las actividades siguientes dependen de los
resultados que se obtengan de ambas migraciones para poder ejecutarse, con lo
que se quedarán en espera hasta el momento en que acaben ambos procesos, el
cual está determinado por la migración más larga, que en este caso es la
migración con ampliación. Luego de analizados los resultados obtenidos se
generarán informes de resultados que se revisarán en la reunión de cierre antes
de dar la fase por terminada. Estas últimas actividades de análisis y revisiones
podrán tardar hasta 9 días antes que finalicen. Las secuencias y duraciones en la
prueba piloto se presentan a continuación:

ID Tarea Predecesoras Duración

10 Segunda fase: Prueba piloto 48,13 días
11 Reunión de lanzamiento de la prueba piloto 9 1 día
12 Migración directa 16,63 días
25 Migración con ampliación 39,13 días
43 Análisis de resultados de la red 29; 22; 23; 40; 41 4 días
44 Análisis de resultados de los clientes 24; 42 4 días
45 Generación del informe de resultados 43; 44 1,5 días
46 Reunión de cierre de la prueba piloto 45 2,5 días
Tabla 31: Secuenciado y duraciones de la segunda fase

• Tercera fase: Esta es la fase que más tardará de todo el proyecto y la más
importante también, su duración aproximada es de 135 días y contemplará todos
los tipos de migraciones. De la misma manera que en la anterior, la fase de
migración de la red de comunicaciones, comenzará con una reunión de
lanzamiento que no tendrá inicio hasta que se haya dado por concluida la prueba
piloto. Luego de la misma se pasarán a ejecutar las migraciones en el resto de
sectores, en las que todas estas se ejecutarán también de forma paralela, de
manera que la duración de la parte del proceso que comprende únicamente la

138
 ejecución de la migración será igual a la del sector con migración de duración
más larga, que en este caso es la migración con construcción. Las actividades de
análisis de resultados y generación de informes se realizarán al finalizar todas las
migraciones dado que dependen de los resultados generados para posteriormente
utilizarlos. A diferencia de la fase anterior, en esta fase no hay reunión de cierre
de fase debido a que la reunión que se realice después será para analizar los
informes de resultados de todo el proyecto y dar a este por finalizado en caso de
estar todo correcto. La tabla con el secuenciado y duración de las actividades de
la migración de la red se muestra a continuación:

ID Tarea Predecesoras Duración

47 Tercera fase: Migración de la red 134,13 días
48 Reunión de lanzamiento del resto de la red 46+1 sem 1,5 días
49 Migración directa 22 días
62 Migración con ampliación 84,38 días
80 Migración con construcción 123,63 días
102 Análisis de los resultados de la red 59; 60; 66; 77; 78; 99; 100; 85 4 días
103 Análisis de los resultados de los clientes 61; 79; 101 6 días
104 Generación del informe de resultados 102; 103 3 días
Tabla 32: Secuenciado y duraciones de la tercera fase

En el caso en concreto del presente proyecto el resto de la zona de la red en donde se

aplicará la migración de tecnologías a parte de la del sector de prueba piloto es
comprendido por tres sectores, que en función de sus características, se ha determinado
que a cada sector se le aplicará un tipo de migración diferente. Es por ello que en la
tercera fase del proyecto se realiza sólo una vez cada una de las tres migraciones.

9.2.8 Cronograma del proyecto:

El cronograma del proyecto de migración es desarrollado en base a la información de

los tiempos, en que destacan principalmente las duraciones y el calendario. El proyecto
tiene la fecha de inicio el día Lunes 3 de Mayo del 2010, y a partir de la misma y una
duración aproximada de 198 días, por lo que si tenemos en cuenta las duraciones y
reglas de sucesión entre actividades descritas en todo el apartado anterior, y el
calendario laboral en vigencia, el cronograma del proyecto detallado por actividades
hasta el segundo nivel de la estructura de subdivisión del trabajo, será de la siguiente
manera:

139
 Gráfico 9: Fechas planificadas de inicio y fin de las actividades

Después de generado el calendario de desarrollo con las fechas de cada una de las
actividades programadas en el proyecto de migración, se puede afirmar que, de no
producirse contratiempos apreciables en la ejecución, el proyecto acabará el día
Miércoles 2 de Febrero del 2011.

Como ya se mencionó en el apartado de las duraciones, en las fases de migración se

tendrá que esperar a que finalicen todas las migraciones en los sectores de la red para
poder continuar, con lo cual éstas serán las principales responsables de las demoras en
la parte de la ejecución técnica del proyecto. Para poder apreciar mejor este tipo de
incidencias y en general el desarrollo en el tiempo de las principales actividades de las
que consta la estructura de subdivisión del proyecto de una manera más gráfica,
concretamente sobre una línea temporal, se ha desarrollado el siguiente gráfico de
duraciones y sucesión de tareas basándose en el calendario del proyecto, con los IDs de
cada una respectivamente:

140
 Gráfico 10: Cronograma planificado de las actividades

Ahora es más apreciable el paralelismo y la diferencia de tiempos entre los tipos de

migración en cada fase, y el tiempo que tienen que esperar los procesos finalizados de
las migraciones más cortas respecto al de las más duraderas para poder continuar con las
actividades siguientes, como por ejemplo es el caso de los procesos 62 y 80, en la que
desde que acaba la 62, hasta que empieza la 102 no hay actividad de ningún otro
proceso que no sea el 80, el cual tarda aproximadamente unos tres meses más que el 62
en finalizar.

9.2.9 Camino crítico:

De la misma manera en la que se ha retratado de forma gráfica el cronograma y las

duraciones de las actividades de todo el proyecto en el anterior gráfico, se puede retratar
el camino crítico del proyecto de comienzo a fin, con la finalidad que se pueda apreciar
de una manera cronológica aquella secuencia continua de actividades conectadas con la
mayor duración en el proyecto.

En el camino crítico, todas las tareas que lo conforman tienen la mayor duración de
realización de forma tal que en conjunto conforman la lista de actividades que es capaz
de determinar el menor tiempo posible para la finalización del proyecto. Su importancia
radica justamente en este punto, debido a que de producirse cualquier retraso en alguna
de las tareas del camino crítico, repercutirá directa y proporcionalmente en la fecha de
finalización de todo el proyecto, de una forma segura y más directa de lo que podría
influir o no un retraso en cualquier otra tarea que no forme parte de dicho camino. En el
gráfico que se presenta a continuación, se listan únicamente las actividades que forman
parte del camino crítico en color rojo, y representados cronológicamente:

141
 Gráfico 11: Camino crítico del proyecto

En el presente caso y como ya se mencionó previamente, la dependencia de la mínima

duración en las fases en las que se realiza migración está marcada por las migraciones
ejecutadas de mayor duración, como la migración con ampliación en el caso de la fase
de prueba piloto, o la migración con construcción en el caso de la fase de migración de
la red. En ambos casos, las demás migraciones acaban antes y las demás actividades
tendrán que esperar para continuar el desarrollo. El camino crítico tiene una similitud en
las migraciones más duraderas de las fases 2 y 3, debido a que ambas poseen dos tareas
que comprenden una parte significativa de la duración de estas, que son la instalación y
activación de los equipos adicionales, y la migración de las líneas. Para el caso de la
migración con construcción además, tiene otros dos puntos críticos, que son la espera de
la respuesta para obtener el permiso de construcción, y la ejecución de las respectivas
obras civiles, que únicamente entre las dos tardan más de tres meses en finalizar. Con
esta información se puede justificar que el proyecto de migración durará como mínimo
los 198 días previstos desde su fecha de inicio, y que si alguna de estas actividades sufre
un retraso, el proyecto entero sufrirá el mismo retraso.

9.2.10 Tiempo adicional del proyecto:

La administración del proyecto ha estudiado los plazos de tiempo para cada actividad y
cada fase del proyecto, y ha decidido agregar al cronograma un margen de tiempo
adicional, del que se hará uso únicamente en caso que por distintos motivos la ejecución
no vaya dentro de los plazos planificados. Luego de analizar los riesgos a los que está
expuesto el proyecto, y las implicaciones del presupuesto en el tiempo, se ha decidido

142
que el margen de tiempo adicional máximo sea del 10,4% de la duración total prevista
para el desarrollo del proyecto. Si el proyecto tiene de duración inicial 1’116 horas,
podrá tener hasta 1’232,14 horas para su finalización. La justificación a esta decisión se
encuentra en el apartado de gestión de riesgos.

9.3 GESTIÓN DE COSTOS Y PRESUPUESTO DEL PROYECTO:

En la gestión de costos y presupuesto se pretende mostrar un análisis detallado de los

gastos que se asumirán en el proyecto de migración, con la finalidad de justificar el
presupuesto del que se dispone y poder establecer así una línea base del flujo de gastos
en el tiempo de duración del proyecto para que posteriormente sirva de guía al momento
de gestionar el desarrollo del proyecto en función de la evolución de los gastos que se
vayan realizando. Para poder analizar los costos se debe tener antes un análisis de los
recursos que se poseen para la realización del proyecto, la utilización que se darán de
los mismos, y la distribución entre las diferentes actividades y sus respectivas
duraciones. El análisis correspondiente de los recursos ya se encuentra efectuado en la
primera parte del apartado de gestión del tiempo, por lo que se proseguirá directamente
con el análisis de costos.

9.3.1 Asignación de costos a las actividades principales:

Para la obtención de los costos se ha tenido en cuenta tanto la asignación de recursos a

cada actividad de la estructura de subdivisión del trabajo, así como el costo de
utilización de cada recurso empleado en cada actividad y su respectiva duración
calculada en función de los recursos asignados. El reparto del presupuesto del proyecto
entre las actividades del primer nivel de la estructura de subdivisión del trabajo
entonces, tendrá la siguiente forma:

ID Tarea Costo
1 Migración de tecnologías en una red telefónica 67.191,00 €
2 Reunión de lanzamiento del proyecto 600,00 €
3 Primera fase: Análisis de la red 2.635,00 €
10 Segunda fase: Prueba piloto 12.800,00 €
47 Tercera fase: Migración de la red 50.196,00 €
105 Reunión de cierre del proyecto 960,00 €
Tabla 33: Costos de las actividades principales

En vista de lo obtenido, la previsión de gastos para cada fase es diferente debido a que
en la fase de análisis de la red están presupuestados aproximadamente 2’700 €, mientras
que las fases de prueba piloto y migración de la red se acercan a los 13’000 y 50’000 €
respectivamente. Ello se debe a la duración desigual de cada fase y la cantidad de
recursos empleados en cada una, ya que en el caso de las reuniones de lanzamiento y
cierre se tratan de actividades cortas sin más subdivisión de tareas, por lo que sus costos
son de 600 y 960 € respectivamente. Todo ello conforma un presupuesto general que
está alrededor de los 67’000 €.

9.3.2 Asignación de costos por tipos de migración:

143
Ya se ha podido notar la gran diferencia de presupuestos entre las diferentes fases de
ejecución, y es principalmente debido a la inclusión o no de procesos de migración de
diferentes tipos, que se detallan a continuación:
• Migración directa: Es la migración de menor coste de todas debido a la relativa
simplicidad de sus tareas, dado que suponen menor cantidad de recursos y
tiempo que otros tipos de migración. Las tareas de esta migración al ser cortas y
casi siempre tener un único recurso asignado, suelen tener costes que oscilan
entre los 20 a 200 €. La excepción es la migración de las líneas, que es una tarea
que puede durar alrededor de 10 días y necesita de dos recursos diferentes para
realizarse, por lo que su costo está en torno a los 1’500 € y es la tarea que
prácticamente duplica el presupuesto de la migración directa. El detalle de los
costos para esta migración se presenta en la siguiente tabla:

ID Tarea Costo
A Migración directa 2.260,00 €
B Comunicación inicial con los clientes 180,00 €
C Configuración de líneas provisionales SDH 180,00 €
D Configuración de la central de conmutación 20,00 €
E Configuración del acceso 160,00 €
F Generación de scripts de migración 160,00 €
G Generación de scripts de conmutación 20,00 €
H Generación de scripts de acceso 140,00 €
I Migración de líneas 1.440,00 €
J Desconfiguración de líneas provisionales 120,00 €
K Desconfiguración de la central de conmutación 40,00 €
L Desconfiguración del acceso 40,00 €
M Comunicación final con los clientes 180,00 €
Tabla 34: Costos de la migración directa

• Migración con ampliación: Su costo general es algo mayor al doble de la

migración directa, debido a las actividades de ampliación de equipos, que es en
lo que difieren ambos tipos de migración. Las tareas de solicitudes y peticiones
son relativamente baratas ya que tienen un único recurso asignado y son cortas,
pero la instalación y activación de los equipos adicionales al durar varios días
(según el sector, puede tardar de 2 a 6 semanas) hace que su costo oscile entre
los 2’000 a 5’000 €, incrementando así notoriamente el presupuesto para este
tipo de migración. La asignación de costos se presenta a continuación:

ID Tarea Costo
A Migración con ampliación 5.440,00 €
B Ampliación de los equipos de acceso 2.180,00 €
C Solicitud de permiso de actuación para instalación 75,00 €
D Solicitud de material 75,00 €
E Pedido de reposición de material 30,00 €
F Instalación y activación de equipos adicionales 2.000,00 €
G Comunicación inicial con los clientes 180,00 €

144
 H Configuración de líneas provisionales SDH 480,00 €
I Configuración de la central de conmutación 320,00 €
J Configuración del acceso 160,00 €
K Generación de scripts de migración 220,00 €
L Generación de scripts de conmutación 100,00 €
M Generación de scripts de acceso 120,00 €
N Migración de líneas 2.080,00 €
Ñ Desconfiguración de líneas provisionales 120,00 €
O Desconfiguración de la central de conmutación 40,00 €
P Desconfiguración del acceso 40,00 €
Q Comunicación final con los clientes 180,00 €
Tabla 35: Costos de la migración con ampliación

• Migración con construcción: El costo total de este tipo de migración es de

29’000 € aproximadamente y llega a ser el más caro de todos. Previsiblemente,
la diferencia de costos entre este tipo de migración y el anterior se debe las
únicas tareas que incluye adicionalmente la migración con construcción dado
que el resto de tareas tienen una distribución y costos similares. De las tareas de
construcción destacan la elaboración del proyecto constructivo, con un coste
cercano a los 500 €, y la ejecución de la obra civil, que es una de las tareas más
largas e importantes de esta migración, llegando a costar más de 21’000 € su
ejecución. La distribución de los costos para cada actividad de la migración con
construcción se pueden apreciar en la siguiente tabla:

ID Tarea Costo
A Migración con construcción 28.406,00 €
B Construcción de la red 24.496,00 €
C Elaboración del proyecto constructivo 480,00 €
D Solicitud del permiso de construcción externo 60,00 €
E Solicitud de material 60,00 €
F Pedido de material 45,00 €
G Ejecución de la obra civil 21.216,00 €
H Instalación de equipos adicionales 2.400,00 €
I Solicitud de activación de equipos 60,00 €
J Activación de equipos adicionales 175,00 €
K Comunicación inicial con los clientes 180,00 €
L Configuración de líneas provisionales SDH 340,00 €
M Configuración de la central de conmutación 240,00 €
N Configuración del acceso 100,00 €
Ñ Generación de scripts de migración 90,00 €
O Generación de scripts de conmutación 60,00 €
P Generación de scripts de acceso 30,00 €
Q Migración de líneas 3.040,00 €
R Desconfiguración de líneas provisionales 80,00 €
S Desconfiguración de la central de conmutación 40,00 €

145
 T Desconfiguración del acceso 40,00 €
U Comunicación final con los clientes 180,00 €
Tabla 36: Costos de la migración con construcción

Es importante el mencionar que si un tipo de migración se aplica más de una vez en el

proyecto de migración, es muy posible que en cada aplicación, los costos de algunas
tareas no sean exactamente los mismos, debido a que los sectores de la red puede tener
diferentes características técnicas, como por ejemplo la magnitud de la obra civil, o la
cantidad de líneas a migrar, las horas requeridas para las configuraciones, entre otros
aspectos. Es por ello que los costos de las actividades de migración presentados en este
apartado son valores reales aproximados.

9.3.3 Asignación de costos a las actividades secundarias:

Una vez conocidos los costos de las actividades para cada tipo de migración a realizar,
se muestran a continuación los detalles de costos para las actividades secundarias de la
estructura de subdivisión del trabajo para las tres fases de ejecución:
• Primera fase: El análisis de la red es la fase menos costosa de las tres debido a
que no incorpora ningún proceso de migración sino únicamente un grupo de
tareas cortas de análisis, realización de informes, comunicación con clientes y
reuniones. Su presupuesto se reparte en seis tareas que cuestan entre 75 a 960 €
y se detallan en la siguiente tabla:

ID Tarea Costo
3 Primera fase: Análisis de la red 2.635,00 €
4 Listado de clientes con HFC 75,00 €
5 Análisis de la red HFC 640,00 €
6 Análisis de la red SDH 320,00 €
7 Análisis de la central de conmutación 320,00 €
8 Informe de estado inicial 320,00 €
9 Definición de la prueba piloto 960,00 €
Tabla 37: Costos de la primera fase

• Segunda fase: La prueba piloto en este caso incorpora en su listado de tareas un

par de migraciones que son la directa y con ampliación. Luego de vistos los
costes por tipos de migración, ambos procesos costarán juntos 7’700 € y se
desarrollarán en paralelo. Las actividades de reuniones en este caso son más
caros que las reuniones del primer nivel de subdivisión debido a que al tratarse
de temas más específicos y con mayor cantidad de detalles, se abordarán con
más tiempo y contarán con más recursos asignados. Lo mismo ocurre con los
análisis de resultados, para llegar a tener una fase con un costo que ronda los
13’000 €. La tabla de costos de dicha fase es la siguiente:

ID Tarea Costo
10 Segunda fase: Prueba piloto 12.800,00 €
11 Reunión de lanzamiento de la prueba piloto 1.080,00 €
12 Migración directa 2.260,00 €

146
 25 Migración con ampliación 5.440,00 €
43 Análisis de resultados de la red 1.280,00 €
44 Análisis de resultados de los clientes 480,00 €
45 Generación del informe de resultados 660,00 €
46 Reunión de cierre de la prueba piloto 1.600,00 €
Tabla 38: Costos de la segunda fase

• Tercera fase: Es la fase más extensa y costosa de las tres fases de ejecución del
proyecto, debido a que acoge tres migraciones cada una en un sector diferente,
incluyendo una del tipo con construcción. Su distribución de actividades es muy
similar a la migración con ampliación, pero en el tema de costos es la más cara
debido a que esta última aplica sólo dos migraciones en un mismo sector. La
fase de migración tiene un costo mayor a los 50’000 € los cuales se asignan
mayormente a las tres actividades de migración. Los detalles de los costos para
las actividades de esta fase se muestran a continuación:

ID Tarea Costo
47 Tercera fase: Migración de la red 50.196,00 €
48 Reunión de lanzamiento del resto de la red 1.440,00 €
49 Migración directa 3.820,00 €
62 Migración con ampliación 13.210,00 €
80 Migración con construcción 28.406,00 €
102 Análisis de los resultados de la red 1.280,00 €
103 Análisis de los resultados de los clientes 720,00 €
104 Generación del informe de resultados 1.320,00 €
Tabla 39: Costos de la tercera fase

La migración con ampliación en la segunda y tercera fase tiene un costo de 5’440 y

13’210 € respectivamente porque como ya se mencionó, son procesos que se aplican el
primero en una parte del sector en donde se realiza la prueba piloto y el segundo en un
sector completo, además de suponer las diferencias mencionadas que se han explicado
previamente.

9.3.4 Línea base del presupuesto:

Para poder tener una idea diferente y complementaria de cómo se hará para gestionar el
presupuesto asignado para el proyecto de migración, en presente apartado se realiza un
análisis temporal de los gastos en el proyecto. La importancia de un análisis temporal
del presupuesto es la de tener un mejor control, dar un mejor rendimiento, y tener una
referencia firme sobre los gastos a realizar para tener de dónde comparar al realizar el
seguimiento y a partir de la cual se podrán sacar conclusiones sobre la evolución de los
gastos.

Ya se ha visto en el apartado anterior la distribución de los gastos para cada actividad de

la estructura de subdivisión del trabajo. Ahora, el primer paso a llevar a cabo en este
nuevo análisis preliminar es la realización de la evolución prevista de los gastos en
función del tiempo. Dada la duración media de las actividades y del proyecto, se ha
decidido que dicha evolución temporal se hará tomando los puntos de medida uno por
147
cada semana, con lo que se logra una buena frecuencia de medición y nivel de detalle
necesario para el análisis sin llegar al punto de saturación de información. El proyecto
abarcará un total de 40 semanas, de las cuales al juntar la información de gastos en cada
una, se obtiene una gráfica de flujo de gastos, que se muestra a continuación:

Flujo de gastos
4.500 €
4.000 €
3.500 €
3.000 €
2.500 €
2.000 €
1.500 €
1.000 €
500 €
0€
1 4 7 10 13 16 19 22 25 28 31 34 37 40

Gráfico 12: Flujo semanal de los gastos planificados del proyecto

Una vez realizado el gráfico, la información es mucho más apreciable que simplemente
tener una tabla con datos numéricos. En el presente gráfico se puede ver que los gastos
no son muy constantes semana a semana y fluctúan bastante a lo largo del desarrollo del
proyecto. En dicho periodo se ven tres claros ‘bajos’ en el flujo de gastos, en las
semanas 7, 19, y 32 respectivamente, lo cual indica que entre éstos hay cuatro periodos
de gastos considerables, que se entienden como cuatro periodos en los que se realizan
una mayor cantidad de tareas o tareas con una mayor asignación de recursos. De estos
cuatro periodos, destaca principalmente el que se encuentra entre las semanas 19 y 32,
que es en donde se realiza un nivel de gastos considerablemente más alto que el resto de
periodos. Es en este periodo justamente es en donde se realizan las tareas de
construcción y obra civil del proyecto, y ésta es principalmente la razón del gran auge
de los gastos entre estas semanas, debido a que se tratan de actividades largas y con
mucha asignación de recursos. Esta parte del análisis preliminar sirve para ver en qué
momentos de la ejecución del proyecto se debe poner especial atención en el correcto
desarrollo de las actividades.

El segundo paso se trata de la realización de una nueva gráfica, que se construye

basándose en la información de la gráfica anterior. La forma de realización se basa en
generar un gráfico con los valores acumulados del flujo de gastos, lo que quiere decir
que para cada punto de medición de los gastos en el periodo de duración del proyecto
(cada semana, en este caso), el valor a representar es igual al mismo valor en el mismo
punto en el gráfico de flujo de costos, más la suma de todos los valores anteriores. A
esta nueva gráfica se le denomina PMB (Project Measurement Baseline) o línea base de
medición de la ejecución, y su forma es representada en el siguiente gráfico:

148
 Línea base (Acumulado)
80.000 €
70.000 €
60.000 €
50.000 €
40.000 €
30.000 €
20.000 €
10.000 €
0€
1 4 7 10 13 16 19 22 25 28 31 34 37 40

Gráfico 13: Línea base de medición de los gastos

Esta información es particularmente importante porque gracias a ella se tendrá una

referencia para la gestión de costos, de modo que se podrá analizar la evolución real de
los gastos del proyecto a lo largo del tiempo e ir comparándola con la línea base de
medición del presupuesto (que representa la evolución planificada de los gastos), y a
partir de ello sacar conclusiones sobre el avance del proyecto, poder ubicar y analizar a
fondo las causas que generaron los posibles puntos de diferencia entre gráficos, y
realizar predicciones sobre la evolución de los gastos en lo que queda del desarrollo.

9.3.5 Presupuesto adicional del proyecto:

De manera paralela a la gestión de tiempos, se analizaron los riesgos respecto a la

gestión de costos en la reunión de planificación, sus implicaciones con la gestión de
tiempos, y la posibilidad de asignación de un margen adicional al presupuesto para
hacerle frente. La administración del proyecto podía aspirar como máximo posible a un
10% del presupuesto inicial previsto, y luego de realizar los análisis correspondientes se
llegó a justificar que el margen adicional máximo de presupuesto que se dispondrá será
finalmente del 8%, que equivale a los 72’566,28 €. Ello se debe a que los estudios
realizados aseguran que con un margen de 7,9% (que equivaldrían a 72’499,68 € de
presupuesto total) se puede asegurar el desarrollo del proyecto con un alto margen de
confianza. La justificación del mismo se encuentra en el apartado de gestión de riesgos.

9.4 GESTIÓN DE RIESGOS EN EL PROYECTO:

9.4.1 Planificación de la gestión de riesgos:

La gestión de riesgos es uno de los apartados más importantes en la fase de

planificación del proyecto porque es en donde se tratan los factores que pueden llegar a
incidir en el normal desarrollo del proyecto y tener un impacto de carácter decisivo en
sus objetivos y evolución. En la planificación de la gestión de riesgos se analizarán al
detalle tanto las amenazas como oportunidades más probables que puedan surgir, así
como la metodología de la gestión que se aplicará para manejarlos.

149
Es de gran importancia para una correcta gestión de riesgos el establecer buenas
comunicaciones internas y externas, así como asegurar que los miembros del equipo de
trabajo compartan una idea común sobre los riesgos, los límites de tolerancia, y los
métodos de tratamiento de riesgos a utilizar. Debido a estas razones se establecerán
reuniones internas y externas periódicamente, en las que en las internas participará todo
el equipo del proyecto, mientras que en las externas se reunirán el administrador y los
coordinadores del proyecto con los patrocinadores del mismo, los cuales están formados
por algunos de los miembros de la directiva de la empresa. Las reuniones internas no
sólo sirven para hablar de riesgos detectados o plantear soluciones, sino para unificar
criterios a la hora de tomar decisiones, recolectar información útil y revisar las posibles
estrategias. En dichas reuniones también se asignarán por parte del gestor del proyecto a
los responsables de cada riesgo, los cuales tendrán que estar pendientes del surgimiento
de la amenaza u oportunidad que le ha sido asignada, realizar seguimientos de la
evolución de la misma, escoger la estrategia o solución más adecuada, llevarla a cabo, y
documentar. Las reuniones externas tendrán como finalidad la comunicación con los
patrocinadores e incluyen el abordaje de temas como la compatibilidad de la
metodología de gestión con la filosofía, valores y forma de actuación de la empresa, los
criterios y valores umbrales para la detección de información importante, toma de
decisiones vitales, y mantener a los patrocinadores constantemente informados de los
cambios y movimientos producidos.

Un aspecto importante de la metodología de la gestión de riesgos será el de revisar

documentación sobre riesgos similares, para disponer de ejemplos previos concisos
sobre cómo se trataron problemas similares en la empresa, así como el de registrar toda
experiencia previa del personal del proyecto en temas similares. En la revisión de
documentación también se incluyen revisiones a los documentos previos del mismo
proyecto, por si un mismo riesgo se vuelve a repetir más adelante en la ejecución. Con
esto se conseguirá aumentar la velocidad de reacción del equipo ante el riesgo, así como
dar más confianza a las medidas y criterios que se tomen para tratar un riesgo, dado que
éstos ya han sido aplicados con éxito en el pasado en un entorno similar al actual. Cada
detección realizada, seguimiento, recogida de información, criterios sobre los niveles
límites en la información para la toma de decisiones, y estrategias y respuestas a realizar
deberán ser debidamente documentados por todos los implicados en el riesgo en
cuestión, de manera que se pueda mantener al administrador, a los coordinadores y a los
patrocinadores correctamente informados, además de tener información útil para que
sea aprovechada en un futuro en el mismo u otros proyectos.

Es responsabilidad del administrador del proyecto para una buena gestión de riesgos el
lograr establecer criterios de ejecución unánimes para que el equipo pueda actuar sin
problemas de incompatibilidad ni disparidad de ideas. Entre los principales criterios a
establecer se tienen:
• Calidad de la información recogida: La detección de un posible riesgo pasa por
un seguimiento constante y recolección de información sobre la que luego se
tomarán decisiones. La calidad de la información por ende será muy importante,
por lo que no se puede dejar de lado la utilización de los métodos más eficaces y
exactos posibles para recoger una información que sea precisa, con el menor
margen de error y la mayor exactitud posibles.
• Objetividad en la recogida de información: Cuando la detección de información
vital para la toma de decisiones es realizada por un humano, éste puede terminar
siendo decisivo sobre todo al tratarse de información relacionada a la

150
 incertidumbre. Por ello, la unificación de criterios de recolección y la
objetividad con la que se recojan los datos es importante para la transparencia de
los mismos a la hora de su análisis.
• Acuerdo en las definiciones y el enfoque: El personal del proyecto que esté a
cargo de gestionar los riesgos que se produzcan debe de estar de acuerdo en
aplicar los mismos criterios y métodos al momento de recolectar información,
analizar, y tomar decisiones, para que no se produzcan diferentes reacciones
frente a un mismo riesgo debido a la diversidad de opiniones entre los
encargados de su gestión y esto pueda repercutir de alguna manera en el
desarrollo del proyecto.
• Unanimidad en los valores límites y tolerancias: De la misma manera en que el
personal del proyecto a cargo de la gestión de riesgos deberá ponerse de acuerdo
en los criterios y definiciones, también tendrán que analizar y acordar unos
valores límites específicos al momento de ver si un riesgo se convierte o no en
un problema (o ventaja) y la respuesta necesaria que tendría. En algunos casos
esta información y sobre todo la de tolerancias deberá ser directamente acordada
entre el administrador del proyecto y los patrocinadores del mismo, y luego ser
comunicada al personal encargado.
• Recursividad en el sondeo y seguimiento de riesgos: La frecuencia de los
sondeos de las actividades que estén en la mira de una posible ocurrencia de un
riesgo deberán ser planificadas y establecidas entre el personal encargado de
dicho riesgo y el administrador del proyecto, de modo que haya coherencia con
las necesidades técnicas de revisión de las actividades, pero tomando en cuenta
los recursos asignados, el tiempo requerido y la importancia del riesgo.
• No ambigüedad en la asignación de roles: La primera reunión del equipo
completo será entre otros motivos para asignar al personal encargado de
gestionar los riesgos que se han decidido son prioritarios o que se deben
mantener controlados. Un riesgo puede tener una o varias personas asignadas,
pero siempre se deberá mantener la independencia en el rol de cada persona por
separado, de manera que la responsabilidad de cada persona asignada quede
claramente definida y no se trasponga con la de otra para evitar problemas de
redundancias de responsabilidades. Mantener bien organizado este aspecto es de
vital importancia porque la posibilidad de desentendimiento que se produce
cuando dos o más personas atienden un error es muy alta y puede conllevar a
problemas mayores o correr con más riegos innecesariamente.

Antes de aplicar una respuesta directamente a un riesgo o escoger una de varias posibles
alternativas, se analizará el riesgo para ver la viabilidad de emplear estrategias contra
los mismos. Dichas estrategias que se utilizarán para dar solución a las amenazas y
oportunidades que puedan surgir durante el desarrollo del proyecto se contemplan:
• Evitar una amenaza o explotar una oportunidad: Es la estrategia más utilizada de
todas, en la que se gestionan directamente las amenazas con la finalidad de
intentar anular su nivel de impacto en el proyecto o hacer que simplemente no
ocurra, y las oportunidades para incrementar su nivel de beneficios cuanto sea
posible, a través de la toma de medidas y acciones correspondientes.
• Transferir una amenaza o compartir una oportunidad: Consiste en apoyarse en
una entidad diferente para el trato de un riesgo debido a que no se puede tratar
con todas las garantías la amenaza o aprovechar del todo la oportunidad.
• Mitigar una amenaza o aumentar una oportunidad: También es una estrategia
ampliamente aplicada, y se basa en identificar acciones que sean capaces de

151
 rebajar la probabilidad de ocurrencia de las amenazas y elevar la probabilidad de
las oportunidades existentes.
• Aceptar una amenaza o una oportunidad: Esta estrategia se utiliza cuando las
demás estrategias no proceden o no son de lo más adecuadas, o cuando el nivel
de impacto es muy bajo. No se toman medidas concretas mientras el riesgo no se
dé, y si éste se llega a dar, se pasa a aplicar un plan de contingencia que se
deberá haber desarrollado cuando surgió el riesgo.

La correcta clasificación de los riesgos a través de las causas que la generan brindará
una buena base para comprender a los riesgos latentes, y luego tener una mejor visión
para la gestión de los mismos y la prevención de más riesgos similares. La estructura de
subdivisión de los riesgos o RBS (Risk Breakdown Structure) se basará en la
categorización de los riesgos, la cual a su vez adoptará la propuesta del libro PMBOK,
debido a que este último describe y separa apropiadamente las causas que pueden tener
los riesgos en el presente proyecto. Las categorías en las que se clasificarán los riesgos
son las siguientes:
• Riesgos técnicos: Son los riesgos que se pueden generar debido a razones
puramente técnicas, tanto por parte de fallos del equipo técnico como de los
diferentes materiales y dispositivos a utilizar. Están entre los riesgos más
comunes, pero suelen ser de rápida solución.
• Riesgos externos: Conjunto de riesgos que no tienen su origen dentro de los
límites del proyecto, se general ya sea debido a clientes, empresas
subcontratadas u otros factores externos.
• Riesgos organizacionales: Estos riesgos son generados en la empresa u
organización a cargo del proyecto, y suelen comprometer al proyecto debido a
temas como la financiación, recursos, prioridades, normativas internas, entre
otros.
• Riesgos de administración: El origen de los riesgos de administración es la
gestión del proyecto, y están relacionados con errores o mejoras en los apartados
de planificación, estimaciones, gestión de las comunicaciones, etc.

Una vez conocidas las categorías principales en las que se clasificarán los riesgos según
sus fuentes o motivos de origen, la estructura de subdivisión de los riesgos es realizada
sobre ésta, incluyendo dos niveles de jerarquía. La representación gráfica de la RBS
teórica es mostrada a continuación:

152
 Gráfico 14: Estructura de subdivisión de los riesgos teórica

La verdadera plantilla sobre la que se ha realizado esta RBS teórica puede llegar a tener
una mayor cantidad de tipos de riesgos de segundo nivel o hasta un tercer nivel, pero
ello siempre está en función del tipo de empresa, entorno, proyecto y características
sobre las que se estén trabajando. En el caso del presente proyecto, los motivos que
figuran en el RBS presentado incluyen todas las causas potenciales desde las cuales
pueden surgir todos los riesgos posibles que han sido evaluados por el equipo del
proyecto en la planificación.

9.4.2 Identificación de riesgos:

La identificación de los riesgos es un proceso recursivo que se realizará a lo largo de la

ejecución del proyecto con una cierta frecuencia determinada a través del monitoreo
continuo de riesgos, para poder detectar nuevas amenazas u oportunidades, y poder
analizarlos para que luego éstos sean gestionados adecuadamente. En la fase de
planificación del proyecto de migración se realizó una primera reunión para la
identificación de los riesgos principales previos a la ejecución del riesgo, tomando en
cuenta la opinión del personal con experiencias previas, personal experto en el tema, un
análisis técnico de las actividades, y revisión de documentos anteriores relacionados.

A continuación se propone un listado y definición de los principales riesgos detectados

‘a priori’ y escogidos, que pueden tener consecuencias importantes en alguno o más de
los objetivos del proyecto. Es importante resaltar el hecho que los riesgos que se
presentan en este apartado no son necesariamente todos los que puedan tratarse en el
presente proyecto, sino únicamente los que se han detectado antes de proceder con la
fase de ejecución. Existe la posibilidad que se puedan dar más riesgos a lo largo del
desarrollo del proyecto y para ello se realizará un monitoreo y gestión continuos de los
riesgos en el proyecto. Luego de cada definición en el listado de riesgos a continuación,
se ha agregado una breve explicación de los objetivos del proyecto a los que el riesgo
puede llegar a afectar. Los riesgos a tener en cuenta son los siguientes:

153
• Negativa de los usuarios a realizar la migración: En caso que una cantidad
significativa de los usuarios de uno o más sectores en donde se planea realizar la
migración se nieguen a que les cambien el servicio que han contratado. Si esta
amenaza podría afectar la duración del proyecto o en el peor de los casos, evitar
su continuación.
• No localización de los usuarios: Si al momento de contactar a los usuarios para
realizar el listado inicial, no se consigue localizar a una cantidad significativa de
ellos. Los daños que podría causar este riesgo en el proyecto son los mismos que
los del riesgo anterior.
• No lograr la dispersión mínima de los usuarios en la red: Cuando se da el caso
que no se puede realizar la migración en uno o más sectores de la red debido a
que no se ha alcanzado la dispersión mínima de usuarios que hayan aceptado el
cambio en el servicio. De la misma manera que los riesgos anteriores, esta
amenaza puede comprometer desde la duración del proyecto hasta su viabilidad.
• Demoras en la instalación por problemas técnicos: Si en las diversas actividades
técnicas programadas en la estructura de subdivisión del trabajo a realizarse, el
tiempo de ejecución de las mismas excede de manera significativa el estipulado
debido a cualquier complicación de índole técnica que pueda surgir. Los
objetivos afectados por una ocurrencia de esta amenaza serían los de la duración
y el presupuesto.
• Riesgos surgidos desde la empresa subcontratada: Si la empresa subcontratada
no cumple con los plazos previstos, si llega a determinar que el importe por su
servicio debe ser mayor al pactado inicialmente, o si llegan a tener fallos o
generar problemas técnicos que puedan repercutir en el desarrollo del proyecto.
Las consecuencias de este riesgo pueden ser muy variadas e implicar desde
simples demoras en el desarrollo del proyecto, hasta el replanteamiento o
cancelación del mismo.
• Demoras en la entrega de los equipos solicitados: Los equipos de la nueva
tecnología que se soliciten para reemplazar a los de la tecnología antigua se
pedirán a través de una empresa proveedora, en el que existe el riesgo que estos
equipos tarden considerablemente en llegar desde su origen por diversos
motivos. Esta amenaza afectaría directamente a la duración del proyecto.
• Falta de comunicación efectiva o con demoras importantes: En caso que la
comunicación entre departamentos de la empresa o entre la empresa y agentes
externos no sea adecuada o no se produzca a tiempo y esto tenga consecuencias
en incompatibilidades técnicas, demoras en actividades, o costos excesivos. Las
consecuencias de este riesgo pueden ser también muy diversas en función de con
qué intensidad se dé, en qué momento, y en qué condiciones. Pueden llegar a
afectar al proyecto desde la generación de simples demoras en la ejecución hasta
fallos de grandes magnitudes en diferentes rubros que puedan llegar a
comprometer el futuro del proyecto.
• Demoras en los trámites de las peticiones: Todas las peticiones de materiales a
empresas proveedoras y de construcción en los diversos ayuntamientos corren el
riesgo de demorar más de lo previsto inicialmente y tener repercusiones en el
desarrollo del proyecto. Las repercusiones pueden ser además de generar atrasos
importantes en el desarrollo, añadir gastos no previstos, o cambiar el alcance del
proyecto respecto a los sectores en donde se realizarán las migraciones.
• Falta de equipos necesarios para la migración: Amenaza que surge a partir de la
posibilidad de error en el cálculo de los equipos necesarios para la migración o
que por necesidades surgidas en plena ejecución, la cantidad de equipos

154
 necesarios sea mayor. Este riesgo en ningún caso podrá comprometer el futuro
del proyecto pero sin lugar a duda aumentar el costo de los materiales al tener
que hacer más pedidos y por ende retrasar también la ejecución.
• Desacuerdos entre los especialistas sobre temas técnicos: Puede darse el caso
que los especialistas consultados no se lleguen a poner de acuerdo al momento
de tomar decisiones importantes sobre temas técnicos cruciales en la realización
de la migración. Este riesgo sin lugar a dudas afectaría al proyecto generando
retrasos de planificación y análisis diversos.
• Exceso del tiempo y/o presupuesto máximo previsto: Las actividades de la
estructura de subdivisión del trabajo en el proyecto tienen un tiempo y costo
previstos para su realización, y pueden tener pequeñas demoras o pequeños
excedentes en el costo que no son significativos pero que si se comienzan a
acumular en varias tareas, puede devenir en un exceso de tiempo y/o
presupuesto considerables para los intereses del proyecto.
• Problemas o quejas con el nuevo servicio ofrecido: Si se comienzan a recibir
llamadas o avisos por parte de una cantidad considerable de usuarios del nuevo
servicio informando que éste no se está prestando correctamente, o se detectan
fallos en las características del servicio final. Esta amenaza compromete el
objetivo de lograr que el servicio final sea de calidad y por lo tanto, en función
del problema o problemas que afecten al servicio, puede comprometer tiempo y
presupuesto únicamente el revisar y diagnosticar lo que ocurre, y más si se
tratase de un problema grave, que incluiría también cortes en el servicio y más
inconvenientes a los usuarios migrados.
• Incompatibilidad entre los distintos informes generados: Al producirse la
detección posterior por medio de pruebas de verificación, de un posible error en
la ejecución del alguna actividad y que este no figure en los informes que se
realizaron en su momento puede suponer contratiempos importantes para poder
darle solución. Sólamente volver a revisar los informes y en su caso comprobar
todos los datos de nuevo supondría tiempo y dinero para la administración del
proyecto, eso sin tomar en cuenta que simplemente se trate de un error en los
informes y no en la realidad, lo que podría involucrar riesgos secundarios y
aumentar el impacto del mismo en los objetivos.
• Aumento en el precio del nuevo servicio ofrecido: La prestación del nuevo
servicio a los usuarios incorpora mejoras y nuevas características respecto al
servicio anterior, por lo que esto se puede representar en un mayor precio a
abonar por el nuevo servicio otorgado. El beneficio obtenido en caso de darse la
oportunidad sería directa y únicamente el económico.
• Reducción de los plazos de la ejecución: Al tratarse la tercera fase con la
experiencia y datos de los resultados de la segunda fase de prueba piloto y que
no se presenten mayores inconvenientes, las actividades de la tercera fase se
pueden desarrollar de una manera más rápida de la estipulada. Una reducción en
los plazos no únicamente beneficiaría al objetivo de duración del proyecto sino
que directamente beneficiaría también una disminución proporcional en el
presupuesto del proyecto.
• Reducción del presupuesto de la ejecución: Una mayor experiencia por parte del
equipo técnico del proyecto al haber realizado anteriormente la primera
migración en la fase de prueba piloto, puede hacer que se reduzca la cantidad de
material y/o equipos a utilizar; o por otro lado, una reducción en los plazos de
ejecución puede significar una reducción en el presupuesto de las actividades
implicadas. Esta oportunidad es muy similar a la anterior, y el beneficio

155
 obtenido en el rubro del presupuesto también se podría extrapolar al de la
duración de la ejecución.

Los riesgos y las respuestas que se le aplican son encargados a Risk Owners y Risk
Action Owners respectivamente. Un Risk Owner o encargado de un riesgo es la persona
(o conjunto de personas) encargada de sondear la ejecución para ver que el riesgo no
ocurra y en caso este surja, decidir las medidas que se llevarán a cabo. Un Risk Action
Owner o encargado de las acciones contra un riesgo es una persona que tiene la
responsabilidad de llevar a cabo las acciones planificadas para contrarrestar el riesgo y
monitorearlas continuamente. En el caso del presente proyecto de migración, la
administración del proyecto ha decidido que dadas las características del proyecto, la
persona o conjunto de personas a la que se asigne un riesgo ejercerá ambos roles a la
vez. Entonces, la asignación de recursos para la gestión de los riesgos es:

Riesgo Recursos
Falta de equipos necesarios para la migración T-Conm; T-Acc
Demoras en la instalación por problemas técnicos Inst-Act; Op-R
Problemas o quejas con el nuevo servicio ofrecido C-Com; G-Cli
Riesgos surgidos desde la empresa subcontratada Contr-C
Demoras en la entrega de los equipos solicitados Contr-C
Demoras en los trámites de las peticiones Adm-R
Negativa de los clientes a realizar la migración C-Com
No localización de los usuarios G-Cli
No lograr la dispersión mínima de los usuarios en la red C-Ing; C-Com
Aumento en el nuevo precio del servicio ofrecido C-Com
Exceso del tiempo y/o presupuesto máximo previsto C-Ing
Desacuerdos entre los especialistas sobre temas técnicos C-Ing; C-Const
Reducción de los plazos de la ejecución C-Ing
Reducción del presupuesto de la ejecución C-Ing
Falta de comunicación efectiva o con demoras importantes C-Ing
Incompatibilidad entre los informes generados T-Acc; T-Conm; G-Cli
Tabla 40: Asignación de recursos a los riesgos

En la lista de riesgos preseleccionados, no todos ellos llegarán a ser resueltos en caso de

ocurrir la amenaza u oportunidad correspondiente, ello estará en función del nivel de
prioridad que tenga cada uno de estos riesgos. Para los riesgos que no hayan sido
clasificados finalmente como prioritarios, los responsables de dicho riesgos únicamente
de realizar un seguimiento del riesgo, verificar que el nivel de impacto en los objetivos
no se incremente (o sí, en caso se trate de una oportunidad), e ir documentando cada
cierto tiempo. Si luego el nivel del riesgo pasa el valor umbral y es considerado
prioritario, el personal a cargo tendrá que proponer una estrategia y solución, y llevarla
a cabo, informando siempre de los cambios y planes al administrador del proyecto.

9.4.3 Análisis cualitativo de los riesgos:

Después de identificar los principales riesgos iniciales que pueden tener impactos
significativos en los objetivos del proyecto, analizar sus posibles consecuencias y
causas, y asignarles recursos para su gestión, se pasará a realizar un análisis más

156
detallado de cada riesgo en particular con la finalidad de clasificarlos según la prioridad
que se les dará. El primer paso será la clasificación de los riesgos preseleccionados
dentro de las categorías de la estructura de subdivisión de los riesgos. La RBS que se
mostrará a continuación será definitiva y a diferencia de la RBS teórica mostrada
anteriormente, no incluye aquellas categorías o subcategorías que no contienen a alguno
de los riesgos preseleccionados. La estructura de subdivisión de los riesgos definitiva al
comienzo de la ejecución del proyecto será la siguiente:

Referencia Riesgo
1 Riesgos técnicos
1.1 Requisitos
1.1.1 Falta de equipos necesarios para la migración
1.2 Complejidad e interfaces
1.2.1 Demoras en la instalación por problemas técnicos
1.3 Desempeño y fiabilidad
1.3.1 Problemas o quejas con el nuevo servicio ofrecido
2 Riesgos externos
2.1 Empresas subcontratadas
2.1.1 Riesgos surgidos desde la empresa subcontratada
2.1.2 Demoras en la entrega de los equipos solicitados
2.2 Normativas
2.2.1 Demoras en los trámites de las peticiones
2.3 Clientes
2.3.1 Negativa de los clientes a realizar la migración
2.3.2 No localización de los usuarios
2.3.3 No lograr la dispersión mínima de los usuarios en la red
3 Riesgos organizacionales
3.1 Prioridades
3.1.1 Aumento en el nuevo precio del servicio ofrecido
4 Riesgos de administración
4.1 Estimación
4.1.1 Exceso del tiempo y/o presupuesto máximo previsto
4.2 Planificación
4.2.1 Desacuerdos entre los especialistas sobre temas técnicos
4.3 Control
4.3.1 Reducción de los plazos de la ejecución
4.3.2 Reducción del presupuesto de la ejecución
4.4 Comunicación
4.4.1 Falta de comunicación efectiva o con demoras importantes
4.4.2 Incompatibilidad entre los informes generados
Tabla 41: Estructura de subdivisión de riesgos práctica

157
Cabe mencionar también que dado este cambio en las categorías y subcategorías de la
RBS en función de los riesgos que aparezcan o sean descartados, la forma de la RBS
definitiva podrá ir cambiando a lo largo de la ejecución del proyecto.

El siguiente paso del análisis cualitativo viene dado por la determinación de la

probabilidad de ocurrencia que puedan tener los riesgos, ya sean amenazas u
oportunidades, en el desarrollo del proyecto de migración. Estos valores se han
escogido tomando en cuenta la opinión de expertos en el tema, la experiencia previa del
equipo del proyecto, y documentos anteriores. Dichos valores para cada riesgo en
particular son mostrados y ordenados por porcentajes en la siguiente tabla:

Riesgo Ocurrencia (%)

Demoras en la instalación por problemas técnicos 90%
Aumento en el nuevo precio del servicio ofrecido 90%
Exceso del tiempo y/o presupuesto máximo previsto 85%
Demoras en los trámites de las peticiones 80%
Riesgos surgidos desde la empresa subcontratada 70%
Reducción de los plazos de la ejecución 55%
Reducción del presupuesto de la ejecución 45%
Incompatibilidad entre los informes generados 30%
Demoras en la entrega de los equipos solicitados 25%
No localización de los usuarios 20%
Falta de comunicación efectiva o con demoras importantes 15%
Falta de equipos necesarios para la migración 15%
Problemas o quejas con el nuevo servicio ofrecido 10%
Negativa de los clientes a realizar la migración 10%
No lograr la dispersión mínima de los usuarios en la red 10%
Desacuerdos entre los especialistas sobre temas técnicos 10%
Tabla 42: Probabilidad de ocurrencia de los riesgos

La mayoría de los riesgos identificados inicialmente no supera el 50% de probabilidad

de ocurrencia, lo que quiere decir que son pocos los riesgos que realmente puedan llegar
a ocurrir. Los riesgos con una probabilidad de ocurrencia menor al 10% no son tomados
en cuenta para su gestión, pero como ya se mencionó anteriormente, se tienen en cuenta
al momento de realizar seguimientos del desarrollo del proyecto y ver si su probabilidad
de ocurrencia se ha incrementado en algún punto más avanzado de la ejecución o si han
surgido nuevos riesgos. Este aspecto de los riesgos es una de las razones por las que han
sido preseleccionados para su seguimiento.

Otro aspecto igual de importante para determinar la importancia de un riesgo, y por

ende poder hacer selección de los riesgos prioritarios para la preparación de estrategias
y respuestas es la determinación del nivel de impacto que el riesgo pueda tener en los
objetivos del proyecto. Teóricamente el análisis del nivel de impacto se realiza en dos
ámbitos por separado, el primero es un valor que se mide respecto al objetivo (u
objetivos) afectado en concreto, y el segundo se mide respecto al global del proyecto.
En el caso del presente proyecto se realizará un único análisis de nivel de impacto por
cada riesgo, debido a que no se trata de un proyecto de magnitudes muy grandes como
para tener muy bien diferenciados ambos análisis necesariamente; un único análisis

158
puede también ser adecuado para las necesidades del proyecto. Otro motivo es que cada
objetivo tiene una importancia determinada respecto al global del proyecto, y esto se
puede traducir numéricamente para transformar el nivel de impacto obtenido sobre los
objetivos afectados al nivel de impacto en el global del proyecto, que es lo que se ha
realizado en el caso del proyecto de migración para unificar el análisis. El resultado de
dicho análisis para cada riesgo es representado en un valor en la escala del 0 al 20 según
el nivel de impacto en el proyecto, y es presentado a continuación de forma ordenada en
la siguiente tabla:

Riesgo Nivel de Impacto

Aumento en el nuevo precio del servicio ofrecido 18
No lograr la dispersión mínima de los usuarios en la red 18
Negativa de los clientes a realizar la migración 16
Exceso del tiempo y/o presupuesto máximo previsto 15
Riesgos surgidos desde la empresa subcontratada 14
No localización de los usuarios 14
Reducción del presupuesto de la ejecución 13
Demoras en los trámites de las peticiones 12
Problemas o quejas con el nuevo servicio ofrecido 11
Reducción de los plazos de la ejecución 11
Falta de comunicación efectiva o con demoras importantes 10
Demoras en la entrega de los equipos solicitados 9
Desacuerdos entre los especialistas sobre temas técnicos 8
Demoras en la instalación por problemas técnicos 7
Incompatibilidad entre los informes generados 6
Falta de equipos necesarios para la migración 5
Tabla 43: Nivel de impacto de los riesgos

El riesgo con el menor nivel de impacto posible en la tabla no baja de un valor igual a 5,
debido a que en la preselección de los riesgos iniciales, también se tuvo como criterio
este aspecto que es uno de los más importantes al reflejar directamente los daños (o
beneficios, según sea el caso) que podría llegar a causar en el alcance del proyecto de
ocurrir el riesgo. La mayoría de los riesgos en la lista supera el 10, lo que quiere decir
que son varios los riesgos que más podrían llegar a comprometer el desarrollo del
proyecto.

Los valores de probabilidad de ocurrencia y nivel de impacto son importantes por sí

mismos para el análisis de la importancia de cada riesgo, pero la combinación de ambos
valores es un factor que llega a resultar determinante para la priorización final y
extracción de conclusiones sobre un riesgo dado. Para analizar estos dos valores
conjuntamente se ha aplicado el método de la matriz de probabilidad e impacto, que
consiste básicamente en una tabla en la que ambos ejes están formados por los distintos
valores del nivel de impacto y la probabilidad de ocurrencia normalizados a 1. Esto da
como resultado que las celdas de la tabla contengan una variedad de valores que pueden
ir de 0 a 1 y que indican numéricamente la prioridad que tiene el riesgo analizado en la
matriz para su gestión. La matriz utilizada para la priorización de los riesgos iniciales
preseleccionados es la siguiente:

159
 P.O. Amenazas Oportunidades
0,90 0,22 0,27 0,36 0,45 0,54 0,63 0,72 0,81 0,81 0,72 0,63 0,54 0,45 0,36 0,27 0,22
0,80 0,20 0,24 0,32 0,40 0,48 0,56 0,64 0,72 0,72 0,64 0,56 0,48 0,40 0,32 0,24 0,20
0,70 0,17 0,21 0,28 0,35 0,42 0,49 0,56 0,63 0,63 0,56 0,49 0,42 0,35 0,28 0,21 0,17
0,60 0,15 0,18 0,24 0,30 0,36 0,42 0,48 0,54 0,54 0,48 0,42 0,36 0,30 0,24 0,18 0,15
0,50 0,12 0,15 0,20 0,25 0,30 0,35 0,40 0,45 0,45 0,40 0,35 0,30 0,25 0,20 0,15 0,12
0,40 0,10 0,12 0,16 0,20 0,24 0,28 0,32 0,36 0,36 0,32 0,28 0,24 0,20 0,16 0,12 0,10
0,30 0,07 0,09 0,12 0,15 0,18 0,21 0,24 0,27 0,27 0,24 0,21 0,18 0,15 0,12 0,09 0,07
0,20 0,05 0,06 0,08 0,10 0,12 0,14 0,16 0,18 0,18 0,16 0,14 0,12 0,10 0,08 0,06 0,05
0,10 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,09 0,08 0,07 0,06 0,05 0,04 0,03 0,02
N.I. 0,25 0,30 0,40 0,50 0,60 0,70 0,80 0,90 0,90 0,80 0,70 0,60 0,50 0,40 0,30 0,25
Tabla 44: Matriz de probabilidad e impacto de los riesgos
(P.O.: Probabilidad de ocurrencia; N.I.: Nivel de impacto)

La matriz de probabilidad e impacto utilizada ha sido dividida en tres zonas de prioridad

que vienen a ser prioridad alta (gris oscuro), prioridad intermedia (gris medio), y
prioridad baja (gris claro). La zona de alta prioridad comprende todos los riesgos que
tengan un valor superior a 0,30 como resultado, mientras que los valores desde 0,18
hasta 0,30 pertenecen a la zona intermedia, y desde 0 hasta 0,17 pertenecen a la zona de
baja prioridad de la tabla.

La importancia de este análisis radica en que separa los riesgos prioritarios del resto de
riesgos preseleccionados, para que éstos puedan tener un tratamiento más adecuado
debido a su prioridad. Los riesgos de la zona de prioridad alta son considerados como
los más importantes debido a que son riesgos que no únicamente tienen una alta
probabilidad de ocurrir, sino también que si llegan a darse, pueden tener consecuencias
muy importantes para los intereses del proyecto. Es por ello que los riesgos de alta
prioridad serán los únicos a los que se tratará con estrategias y respuestas más agresivas,
y tendrán reservados un cierto presupuesto para su gestión y solución. Los riesgos de
prioridad intermedia también tendrán un plan de gestión propuesto y serán seguidos de
cerca por los responsables a cargo, pero no se les será asignado un presupuesto efectivo
a menos que en los sondeos posteriores se determine que el riesgo haya pasado a ser
prioritario. En el caso de los riesgos bajos, la única función del equipo responsable será
la de mantener una constante revisión en las causas y en la evolución del riesgo para
asegurar que este no aumente su nivel de prioridad.

Los resultados finales de la aplicación de la matriz de probabilidad e impacto en los

riesgos preseleccionados son finalmente los que dan una mejor visión de la importancia
de cada riesgo por separado y la prioridad que se les será asignada para su posterior
gestión. Luego de aplicado el método de la matriz de probabilidad e impacto a los
riesgos iniciales preseleccionados, los resultados definitivos obtenidos son presentados
en la siguiente tabla con todos los riesgos ordenados por prioridad:

Referencia Riesgo Valor

3.1.1 Aumento en el nuevo precio del servicio ofrecido 0,81
4.1.1 Exceso del tiempo y/o presupuesto máximo previsto 0,64
2.1.1 Riesgos surgidos desde la empresa subcontratada 0,49

160
 2.2.1 Demoras en los trámites de las peticiones 0,48
1.2.1 Demoras en la instalación por problemas técnicos 0,32
4.3.1 Reducción de los plazos de la ejecución 0,30
4.3.2 Reducción del presupuesto de la ejecución 0,29
2.3.2 No localización de los usuarios 0,14
2.1.2 Demoras en la entrega de los equipos solicitados 0,11
2.3.3 No lograr la dispersión mínima de los usuarios en la red 0,09
4.4.2 Incompatibilidad entre los informes generados 0,09
2.3.1 Negativa de los clientes a realizar la migración 0,08
4.4.1 Falta de comunicación efectiva o con demoras importantes 0,08
1.3.1 Problemas o quejas con el nuevo servicio ofrecido 0,06
4.2.1 Desacuerdos entre los especialistas sobre temas técnicos 0,04
1.1.1 Falta de equipos necesarios para la migración 0,04
Tabla 45: Clasificación de los riesgos por prioridad

Finalmente se han obtenido cinco de los dieciséis riesgos en la zona de alta prioridad,
entre ellos y con los valores más altos, el aumento en el nuevo precio del servicio
ofrecido y el exceso del tiempo y/o presupuesto máximo previsto. El resultado de la
zona de alta prioridad sugiere que se debe poner especial énfasis en evitar que ocurran
demoras significativas en la ejecución del proyecto, además de controlar bien las
comunicaciones y responsabilidades con la empresa subcontratada. El aumento del
precio será una tarea en la que su viabilidad tendrá que ser analizada al detalle por parte
de los responsables para saber hasta qué punto se puede llegar a aprovechar, y tomar
una decisión de acuerdo a ello.

En la zona de media prioridad se tienen las reducciones de plazos y presupuesto, debido

a que la posibilidad de sacar un óptimo rendimiento al proyecto en ambos aspectos es lo
suficientemente importante como para realizar seguimientos continuos de dichos riesgos
con la intención de intensificar sus probabilidades y proponer las estrategias o
respuestas posibles. Estos dos riesgos son antagónicos con el riesgo de exceso de
tiempo y/o presupuesto máximo previsto debido a que cada actividad a realizar, y en
consecuencia todo el proyecto en sí, tiene un determinado rango de posibilidades en las
que pueden ocurrir sus respectivas duraciones y costos, entonces pueden ocurrir ambas
posibilidades, que son la de que el proyecto tenga una menor duración y/o coste, o que
sean mayores a lo previsto.

La zona de baja prioridad alberga nueve de los dieciséis riesgos preseleccionados, lo

que quiere decir que no es muy probable que estos riesgos ocurran y tengan
consecuencias importantes en el proyecto. De todas maneras, los responsables
asignados de cada uno de estos riesgos realizarán tareas de seguimiento y control para
evitar que los riesgos aumenten significativamente su probabilidad de ocurrencia o nivel
de impacto. Esto se debe a que estos riesgos fueron seleccionados entre varios otros
debido a que es interés de la administración del proyecto asegurar que ninguno de estos
riesgos seleccionados en particular pueda llegar a ocurrir (o sí, si se trata de una
oportunidad), y aún teniendo inicialmente un valor de análisis final muy bajo se deben
mantener así a lo largo de la ejecución del proyecto.

161
Nótese que en la tabla de resultados son presentados indistintamente las amenazas y
oportunidades, debido a que en la presente matriz de probabilidad e impacto los valores
de las diferentes zonas de riesgo están distribuidos de la misma manera en ambos lados
de la tabla, lo que quiere decir que tanto una amenaza como una oportunidad serán
priorizados únicamente en función del valor numérico obtenido en el análisis.

9.4.4 Análisis cuantitativo de los riesgos:

El análisis cuantitativo de los riesgos es una parte importante de la gestión de riesgos

que surge como una consecuencia del análisis cualitativo, y en donde se pasan a analizar
los principales riesgos desde una óptica más general, viendo las posibles consecuencias
en el proyecto de una manera más tangible y global en vez de individualizada y
diferenciada por objetivos afectados, extrayendo datos numéricos sobre los cuales se
podrán sacar conclusiones de carácter vital para la gestión de los riesgos y para la
gestión del proyecto. Para otros proyectos de menor envergadura, es suficiente con
realizar el análisis cualitativo a fin de tener una buena idea de cómo afectarán los
riesgos al proyecto, pero en el caso del presente proyecto de migración es importante
contar con toda la información que se pueda extraer para justificar adecuadamente las
acciones tomadas, el presupuesto y los plazos requeridos y adicionales.

El análisis de las causas de los riesgos es uno de los factores más importantes a tener en
cuenta en la gestión, y sobre todo cuando son varios los riesgos que tienen la misma
causa en común. En el proyecto de migración, las principales causas de riesgos vienen
dadas tanto por los factores externos como por la administración del proyecto, debido a
que doce de los dieciséis riesgos iniciales preseleccionados provienen de estas dos
fuentes. Ello quiere decir que si varios riesgos tienen una fuente en común, se pondrá
especial énfasis en hacer seguimientos continuos y detallados de dichas causas para
evitar (o generar) que los riesgos ocurran o que surjan riesgos adicionales. Otra fuente
de riesgos que no se puede dejar de lado es la de los riesgos técnicos, porque aunque no
se traten de riesgos que afecten en gran magnitud al proyecto, son los que más ocurren y
generan demoras en la ejecución debido a la propia naturaleza técnica del proyecto.

Otra manera para poder continuar con el análisis generalizado de los riesgos es la
identificación de los potenciales riesgos globales, o aquellos riesgos que son capaces de
comprometer la mayoría o totalidad de objetivos en caso de que ocurriesen, o inclusive
llegar a cambiar el rumbo del proyecto. En el presente proyecto se consideran a seis de
los dieciséis riesgos preseleccionados dentro de esta categoría que vienen a ser:
• Aumento en el nuevo precio del servicio ofrecido
• Exceso de tiempo y/o presupuesto máximo previsto
• Riesgos surgidos desde la empresa subcontratada
• No lograr la dispersión mínima de los usuarios en la red
• Negativa de los clientes a realizar la migración
• No localización de los usuarios
De estos seis riesgos, únicamente uno de ellos es una oportunidad, mientras los otros
cinco se tratan de amenazas, y entre los cuales se encuentran los tres riesgos que tienen
como origen a los clientes, que se consideran como un factor externo al proyecto.

Cabe mencionar que algunos de los riesgos iniciales preseleccionados son riesgos
genéricos que engloban una cierta cantidad de pequeños riesgos con idénticas causas y
consecuencias, y tratamiento similar, y que si son analizados por separado no tendrían

162
una probabilidad de ocurrencia o nivel de impacto significativos, pero en conjunto
conforman riesgos que son de interés para la administración del proyecto el mantenerlos
controlados. Se tratan de riesgos como por ejemplo los surgidos desde la empresa
subcontratada, las demoras por problemas técnicos, o el exceso de tiempo y/o
presupuesto máximo previstos. En el caso de los riesgos surgidos con los clientes como
causa común, se ha decidido no englobarlos en un mismo riesgo debido a que aún
teniendo las mismas causas y efectos, son riesgos que tendrán tratamientos distintos.

La herramienta elegida para la realización del análisis cuantitativo definitivo de los

riesgos en el proyecto será la simulación de Monte Carlo. Lo que se obtiene al aplicar
esta herramienta es un resultado con valores y márgenes reales de alta precisión que
refleja cómo pueden llegar a influir los riesgos globales y los niveles de incertidumbre
en el desarrollo del proyecto, en comparación de lo previsto inicialmente. Esto se
obtiene realizando una serie de simulaciones con información de duraciones y costos
reales, además de incluir el mejor y peor escenario posible. Una vez obtenidos los
resultados de las simulaciones, se extraen otros resultados como consecuencia de un
análisis probabilístico de los resultados de las simulaciones, y que describen lo que
podría llegar a durar y costar el proyecto.

Para poder aplicar la simulación de Monte Carlo al proyecto de migración se han

escogido cuidadosamente los rangos de duración y costos que pueden llegar a tomar
cada una de las actividades de la WBS por separado, teniendo en cuenta para los
mismos los riesgos que pueden llegar a afectar al desarrollo del proyecto y de cada tarea
o conjunto de tareas en particular. Los resultados de la simulación para la duración y
costos se han obtenido y analizado de maneras separadas, debido a que cada una tiene
diferentes requisitos de información para su realización.

La primera simulación de Monte Carlo se realizó para analizar la duración del proyecto
y las consecuencias de los riesgos en este aspecto. Para su realización se utilizó
únicamente la información de la lista de actividades que conforman el camino crítico
del proyecto, el cual consta de toda la cadena de tareas que determinan la mínima
duración posible del proyecto. La duración de cada tarea se ha asumido con una
distribución probabilística del tipo Beta, con parámetros de tiempo que varían en
función de sus características y los riesgos a los que está sujeta, además de tener en
cuenta experiencias anteriores e información aportada por el equipo del proyecto. Para
cada simulación de Monte Carlo, los resultados obtenidos son producto de la realización
de 20’000 simulaciones con la ayuda del software RiskAMP, especial para dicho
análisis. Al deber estar todas las duraciones en la misma unidad, se ha realizado el
análisis del tiempo en horas. La suma total de las horas de ejecución del proyecto desde
que empieza la primera tarea hasta el fin de la última es de 1’116 horas, tomando en
cuenta que no existen tareas en el camino crítico que se solapen temporalmente, e
incluyendo los márgenes de tiempo adicionales asignados específicamente a
determinadas tareas. Una vez realizada la simulación, el rango de valores obtenido para
la duración del proyecto es ordenado en percentiles y presentado en las siguientes
tablas:

Percentil 0% 5% 10% 15% 20% 25% 30%

Valor (Horas) 1058,36 1115,67 1126,57 1134,51 1141,04 1146,26 1151,37

163
 Percentil 35% 40% 45% 50% 55% 60% 65%
Valor (Horas) 1156,12 1160,78 1165,27 1169,75 1174,43 1178,96 1183,63

Percentil 70% 75% 80% 85% 90% 95% 100%

Valor (Horas) 1188,91 1194,55 1201,00 1208,32 1218,40 1232,14 1322,56
Tabla 46: Distribución de percentiles de la duración total en horas

Lo que representa cada valor mostrado es un acumulado de los resultados obtenidos en

las simulaciones, por ejemplo: El valor de 1’169,75 horas para el 50% quiere decir que
en la mitad de las simulaciones, los resultados de duración obtenidos han sido menor o
igual a las 1’169,75 horas, o en otras palabras, se puede afirmar con un 50% de nivel de
confianza que la duración del proyecto no será mayor a las 1’169,75 horas. Para una
mejor apreciación de los percentiles, se muestran los valores distribuidos en la gráfica a
continuación:

Gráfico 15: Distribución de percentiles de la duración total en horas

Luego de procesados y analizados los resultados de la simulación de Monte Carlo para

la duración, se llega a la conclusión que es altamente probable que el tiempo que tome
el proyecto en ejecutarse sea ligeramente mayor al planificado, dado que la duración
inicial del proyecto se encuentra entre el 5% y el 6% de probabilidad. El nivel de
confianza con el que se acordó trabajar es del 95%, porque la diferencia de tiempo entre
el 95% y el 100% es significativamente mayor al resto de diferencias entre los valores
de los percentiles contiguos. Además, se tiene que el valor de la duración para el
percentil 95 es de 1’232,14 horas, lo cual representa un 10,4% más de tiempo que la
duración planificada, que es una diferencia que se puede tolerar a la vez que se tiene un
alto nivel de confianza. Si el nivel de confianza fuera del 100% no aumentaría mucho
respecto al 95%, mientras sí aumentaría notoriamente la diferencia de duraciones
máximas toleradas, dado que se estaría admitiendo que el proyecto pueda tardar hasta
1’322,56 horas, que supone un 18,5% más de lo planificado, y ello en la práctica es
inasumible debido a los gastos excesivos que generaría además de que los plazos para la
finalización no lo permiten.

164
La segunda simulación de Monte Carlo es para analizar cómo los riesgos afectarían al
presupuesto del proyecto, y para ello se ha utilizado la lista completa de tareas de la
estructura de subdivisión del trabajo. A cada actividad se le asignó un costo mínimo y
máximo y una distribución de los mismos en función de los riesgos (también en función
de las variaciones en las duraciones de cada actividad asumidas en la simulación
anterior), además de incluir experiencias de proyectos previos, y aportes del equipo del
proyecto. En este caso en análisis también se realizó en base a los resultados de 20’000
simulaciones, y las unidades de los costos se normalizaron en euros. El presupuesto
planificado para el proyecto es de 67’191 € e incluye el coste de todas las actividades
del proyecto de migración. Los resultados de la simulación de Monte Carlo para el
presupuesto se presentan en las tablas a continuación ordenados por percentiles:

Percentil 0% 5% 10% 15% 20% 25% 30%

Valor (€) 64225,72 66824,76 67297,96 67678,79 67989,22 68244,81 68511,63

Percentil 35% 40% 45% 50% 55% 60% 65%

Valor (€) 68747,32 68984,17 69204,07 69435,10 69676,09 69906,48 70161,60

Percentil 70% 75% 80% 85% 90% 95% 100%

Valor (€) 70441,29 70729,50 71028,67 71411,83 71869,21 72499,68 76300,53
Tabla 47: Distribución de percentiles del presupuesto en euros

Los resultados de la simulación revelan que los gastos totales a la conclusión del
proyecto pueden oscilar en el rango de 64’225,72 a 76’300,53 €, dando un margen del
12’074,81 €. Esto es una buena señal porque al tratarse de un margen relativamente
pequeño en comparación al presupuesto inicial (desde el -4,4% hasta 13,5%), reduce
significativamente los valores posibles del presupuesto final, y con ello disminuye la
posibilidad que los gastos sean excesivos. En este caso, el presupuesto planificado para
la ejecución no tiene un buen porcentaje debido a que su nivel de confianza está entre el
8% y el 9%, por lo que es muy probable que los gastos sean algo mayores a lo previsto.
Para visualizar mejor los resultados en percentiles, se muestra la siguiente gráfica:

Gráfico 16: Distribución de percentiles del presupuesto en euros

165
De la misma manera que en el análisis de la duración, para el análisis del presupuesto se
acordó trabajar con un nivel de confianza del 95%, el cual representa un valor de
72’499,68 € de presupuesto máximo. Dicho presupuesto equivale a un 7,9% más que el
presupuesto inicial previsto y puede ser costeado sin problemas por la administración
del proyecto. La diferencia con asumir un 100% de nivel de confianza, es que se
trabajaría con un presupuesto de 76’300,53 €, y ello representa un 13,5% más de lo
previsto inicialmente. Entonces, no sería posible asumir el 100% porque como ya se
mencionó en el apartado de iniciación del proyecto, el margen de presupuesto adicional
máximo no podrá ser mayor al 10% sobre el presupuesto inicial previsto. El margen de
12’074,81 € en el que oscila el posible costo final también indica que los riesgos
globales a los que se expone el presupuesto del proyecto no tendrían consecuencias muy
graves en caso de darse. Si se junta este resultado con el del análisis cuantitativo
temporal, y los bajos valores del análisis cualitativo de los únicos riesgos que podrían
llegar a comprometer todo el proyecto (es decir, los riesgos generados por los clientes),
se llega a la conclusión de que el proyecto no únicamente es viable, sino que además
posee un cierto grado de robustez frente a las amenazas a las que está expuesto.

9.4.5 Planificación de respuestas:

Antes de proponer las respuestas que se darán para hacer frente a los principales riesgos
en caso ocurriesen, se hará mención de la política de respuestas acordada para la gestión
de riegos del proyecto. Como primer punto, la administración del proyecto únicamente
trabajará para aplicar respuestas a los riesgos que se hayan clasificado con alta prioridad
luego de su análisis. La lista de riesgos en alta prioridad puede ir cambiando a medida
que se vayan sondeando los riesgos a lo largo de la ejecución, entonces a los nuevos
riesgos de alta prioridad se les evaluará posibles respuestas. Con ello se descarta la
proposición de respuestas a riesgos de baja prioridad, que en todo caso se seguirán
supervisando por los responsables a cargo.

Para los riesgos de prioridad mediana, no es necesario contar con respuestas, pero no se
descarta que se puedan proponer estrategias para su manejo. Cabe recordar además que
en el presente proyecto ha sido determinado que para un riesgo dado, tanto su análisis y
seguimiento, como la proposición de estrategias y/o respuestas y su respectiva ejecución
serán encargados a la misma persona o grupo de personas.

De acuerdo con los criterios expuestos sobre la política de gestión de riesgos del
proyecto de migración, a continuación se proponen las estrategias y respuestas que se
aplicarán para cada riesgo seleccionado:
• Aumento en el nuevo precio del servicio ofrecido: Esta oportunidad ha sido
analizada por la administración del proyecto y como riesgo individual es el que
obtuvo el mayor valor de todos. Al inicio se pensó la aplicación de la estrategia
de aumento de la oportunidad, pero dados los altos valores que obtuvo en los
análisis realizados, se le aplicará directamente la estrategia de explotación de la
oportunidad. La respuesta pasa primero por aprovechar las tareas de contacto
con los clientes para la comunicación del aumento en el coste del nuevo servicio,
además de registrar las opiniones y sugerencias que puedan aportar. Después se
hará un breve estudio de mercado para determinar hasta qué punto se podrá
aumentar el nuevo coste en función de las nuevas características del servicio sin
generar problemas de disconformidad entre los clientes. Para ello también se

166
 utilizará documentación sobre cambios de precio anteriores, en los que los
ligeros aumentos de precio han sido gestionados exitosamente. Una vez
realizados estos pasos, el encargado del riesgo realizará la redacción de un
informe sobre el análisis de la oportunidad, previa comunicación y acuerdo con
la directiva de la empresa, para ser presentado y que reciba la aprobación final.
El aumento en el precio no se hará efectivo hasta que el nuevo servicio esté en
pleno funcionamiento.
• Exceso del tiempo y/o presupuesto máximo previsto: En el caso de amenazas
por tiempos o presupuestos excesivos, se consideran ambas como una misma
amenaza porque casi siempre la ocurrencia de una tiene como consecuencia la
ocurrencia de la otra, y en proporciones similares. Ante este riesgo la estrategia a
utilizar por la administración será la mitigación de la amenaza. De acuerdo a
documentación anterior, la mayor parte de los excesos en presupuesto y/o
tiempo se dan por la suma de pequeños excesos en las tareas, o en todo caso por
grandes excesos puntuales en tareas de alta complejidad o consideradas críticas.
La mitigación de la amenaza intentará reducir la posibilidad que los excesos
ocurran, y ello se logrará a través de continuas revisiones en la ejecución de cada
tarea, la documentación de los procedimientos y de cualquier inconveniente
surgido. La documentación de cada tarea estará a cargo de su responsable, y la
supervisaran los coordinadores de los departamentos involucrados. En caso
detectar un posible exceso en una tarea, el responsable del riesgo se comunicará
con los responsables de la tarea para obtener detalles y acordar una solución. Si
persiste el problema, se informarán a los coordinadores de los departamentos
afectados para tratar la solución.
• Riesgos surgidos desde la empresa subcontratada: Los riesgos surgidos desde la
empresa subcontratada seguirán una clara estrategia definida para su gestión que
es la transferencia de la amenaza. Al momento de contractar a la empresa de
construcción para definir las actividades y servicios a realizar, la administración
del proyecto pondrá como condición no negociable que todo riesgo o perjuicio
surgido desde la empresa externa, deberán ser solucionados o compensados en
su totalidad por ellos mismos, y reducir al mínimo posible los daños tangibles
que puedan causar. Esto incluye la contratación de una tercera empresa que haga
las tareas que la empresa subcontratada no pueda realizar en caso sufrir algún
tipo de percance. Esta estrategia fue aprobada debido a las experiencias previas
con dicha empresa de construcción, y siempre que surgieron contratiempos por
su parte, se hicieron cargo satisfactoriamente.
• Demoras en los trámites de las peticiones: Este riesgo es una amenaza que tiene
de origen causas externas al proyecto o a la empresa misma, y suele ocurrir muy
a menudo, por lo que no se puede hacer mucho para evitarlo. Entonces, se ha
propuesto la estrategia de aceptar la amenaza y llevar a cabo un plan de
contingencia para el mismo en caso llegase a ocurrir. El plan de contingencia
pasa por asignar márgenes de tiempo de espera luego que las actividades de
tramitación de peticiones han sido realizadas. Con ello, las actividades
programadas para ejecutarse luego de finalizados los trámites tendrán que
esperar un tiempo determinado en función del tipo de trámite hecho. En caso de
que un trámite tarde más que el margen asignado, el responsable deberá intentar
contactar la entidad involucrada para preguntar por el estado del trámite o tratar
de agilizar el proceso. Si se da un caso especial, el responsable puede reunirse
con el administrador del proyecto para intentar contactar a la directiva de la
empresa para informar y de ser posible, tome cartas en el asunto. Este riesgo ha

167
 sido revisado también en documentos antiguos que confirman su ocurrencia y
los tratamientos realizados, por lo que en el caso de las peticiones de materiales
a empresas proveedoras, se asignan márgenes que van desde los dos días hasta
un mes. Para los trámites de petición de realización de obras civiles, los
márgenes aumentan y pueden ir desde una semana hasta un mes y medio en
función de la magnitud de la obra y el número de ayuntamientos involucrados en
las peticiones. Dichos márgenes de tiempo ya han sido previstos y asignados en
las reuniones de planificación y forman parte del cronograma inicial del
proyecto.
• Demoras en la instalación por problemas técnicos: La estrategia escogida para
este caso es algo particular, debido a la naturaleza de la amenaza. Se trata de un
riesgo muy común y que no siempre puede ser anticipado con éxito, pero que en
contraparte baja mucho la probabilidad de ocurrencia y el nivel de impacto con
una buena previsión. Dadas estas condiciones, la estrategia a seguir será doble,
primero se aplicará la mitigación de la amenaza a través de una serie de tareas de
anticipación y planificación, y luego en caso de ocurrencia, se aplicará un
inmediato plan de contingencia en función de la causa específica del problema
generado. La mitigación del riesgo se basarán en la planificación y
documentación al detalle de las actividades meramente técnicas, a través de
breves y continuas reuniones de seguimiento entre los coordinadores de los
departamentos involucrados y los técnicos responsables de dichas tareas. Se
basará también en la rápida comunicación entre los responsables del riesgo y de
las actividades técnicas, con la finalidad de comunicar cualquier observación
hecha y lograr anticiparse a algún posible problema. En caso de darse el riesgo,
el primer paso para aplicar la contingencia es diferenciar si el problema es de
aquellos que tienen solución técnica inmediata o si requiere de una toma de
decisiones. Si la contingencia al problema requiere de decisiones, el primer
procedimiento será la revisión del historial de problemas técnicos para contar
con una opción válida sobre cómo puede solucionarse un problema similar. De
no encontrar una respuesta que sea satisfactoria, los responsables del riesgo se
deberán reunir con los responsables de la actividad o actividades involucradas
para estudiar el problema en particular y platear una solución técnica lo más
adecuada posible.

Los riesgos de mediana prioridad no formarán parte del presupuesto activo de la gestión
de riesgos, y únicamente se les aplicarán las respuestas propuestas en caso que pasen a
ser de alta prioridad en los sondeos de riesgos posteriores. De todas maneras se
enunciarán a continuación las respuestas propuestas para dichos riesgos:
• Reducción de los plazos de la ejecución: En la respuesta al riesgo de demoras
por trámites de peticiones, se habló de una serie de márgenes de tiempo
asignados tras cada actividad de tramitación externa de solicitudes. Dicho
margen de tiempo, aunque distribuido en diferentes tareas y de manera no
continua temporalmente, la suma de todos estos tiempos es aproximadamente de
90 días útiles. Dado que este aspecto de la oportunidad está directamente
relacionada con dicha amenaza, y su estrategia es la aceptación, la estrategia será
también la de aceptación de la oportunidad. El otro aspecto de la oportunidad
pasa por reducir directamente los tiempos de ejecución planificados para las
actividades, ya sean técnicas o de otra índole, y para ello únicamente se puede
proponer el aumento de la oportunidad, el cual estará dado por la planificación al
detalle de las tareas a ejecutar, incluida la revisión previa de documentación

168
 antigua para saber cómo se realizaron tareas similares, además de una rápida
comunicación entre el personal para agilizar las labores.
• Reducción del presupuesto de la ejecución: La oportunidad de reducción del
presupuesto de ejecución se separa también en dos posibilidades. La primera es
la reducción de los costos como consecuencia de la reducción del tiempo de
ejecución general del proyecto, y para el cual se deberá aplicar entonces la
misma respuesta. Cabe recordar que este aspecto de la reducción del
presupuesto, directamente relacionado a la reducción de los plazos, es una
oportunidad opuesta a la amenaza de exceso de tiempo y/o presupuesto máximo
previsto, por lo que cualquier acto o factor que favorezca a estas oportunidades,
mermará directamente a la amenaza. La segunda se basa en la realización de una
re-planificación ya sea de actividades, re-cálculo de materiales, aprovechamiento
de recursos, en la medida de lo posible, para lograr oportunidades de reducción
en los costos. En este caso la reducción de presupuesto se considera una
oportunidad diferenciada de la reducción de plazos, porque ambas oportunidades
tienen aspectos propios que no están relacionados entre sí. En el caso de
reducción de tiempos, una reducción significativa en los márgenes de tiempo de
espera para tramitaciones no afectaría mucho en el presupuesto final; y en el
caso de reducción del presupuesto, una disminución en los costos por temas de
re-planificación, no tendría por qué repercutir necesariamente en los plazos.

La gestión de riesgos asumirá activamente las respuestas sólo de los riesgos que sean
prioritarios, y además tendrá en cuenta para la administración del proyecto los tiempos y
el presupuesto que tomará la realización de dichas respuestas. Para las determinaciones
de los plazos y el presupuesto para las respuestas a los riesgos se tendrá únicamente en
cuenta la labor de los responsables de los riesgos en las respuestas en concreto,
omitiendo del análisis las comunicaciones entre el responsable y otras partes internas al
proyecto, sondeos de datos o condiciones, o reuniones de rutina. También se descartará
el aporte adicional que puedan brindar otros colaboradores secundarios como los
responsables de las actividades involucradas, debido a que esto último contará como
costo o tiempo de demora de la actividad involucrada. El análisis temporal y de costos
de las respuestas a los riesgos se presenta a continuación:
• Aumento en el nuevo precio del servicio ofrecido: El recurso asignado para
hacerse cargo de esta oportunidad es el coordinador de comunicación, y el
tiempo que tardará en analizar las respuestas de los clientes, hacer un breve
estudio de mercado y realizar un informe con dicha información y conclusiones,
está estipulado en 20 horas.
• Exceso del tiempo y/o presupuesto máximo previsto: En este caso el responsable
del riesgo es el coordinador de ingeniería, dado que es a su vez el coordinador
del proyecto. Sus funciones directas para esta amenaza son la documentación de
incidencias reportadas y reuniones extraordinarias con los responsables de las
actividades involucradas. El tiempo para la respuesta puede variar mucho, pero
por experiencias previas en la empresa se ha determinado un promedio de 16
horas para las soluciones de riesgos de esta índole.
• Riesgos surgidos desde la empresa subcontratada: Debido a que la estrategia
acordada para hacer frente a este riesgo es la de transferencia de la amenaza y el
responsable de realizarla es la propia empresa subcontratada, no habrá necesidad
de asumir costos adicionales para la respuesta a este riesgo en concreto.
• Demoras en los trámites de las peticiones: El responsable de gestionar este
riesgo es un administrativo de la red, y en caso ocurrir la amenaza lo que se

169
 llevaría a cabo no sería un plan de contingencia. Dentro de dicho plan, la tarea
que deberá realizar directamente el responsable es la de establecimiento de
contacto con la entidad causante de la demora. De todos los trámites previstos de
realizarse en el proyecto y los que pueden demorar más de lo previsto, el tiempo
intermedio de respuesta se estima en 8 horas.
• Demoras en la instalación por problemas técnicos: Este riesgo consta con dos
técnicos responsables a cargo, que son un instalador/activador de equipos y un
operador de la red. Las tareas específicas de las respuestas vienen dadas por la
revisión de documentación anterior y reuniones extraordinarias junto a los
responsables de las actividades involucradas. En total la media del posible
tiempo que tomaría responder a los riesgos de demoras por temas técnicos se
establece en 40 horas para todo el proyecto.

Después de analizar las características de cada riesgo, determinar las estrategias y

respuestas que se aplicarán, y asignar el tiempo, recursos y costos que tomarán en
gestionarse, se ha realizado un estimado del presupuesto que necesitará la gestión de
riesgos para poder dar respuesta satisfactoriamente a los riesgos de alta prioridad. Dicha
estimación total se presenta en una tabla a continuación, junto con los detalles de los
costos de cada riesgo:

Riesgo Recursos Coste Horas Total

Total gestión de riesgos prioritarios 2.960 €
Aumento en el nuevo precio del servicio ofrecido C-Com 40 € 20 800 €
Exceso del tiempo y/o presupuesto máximo previsto C-Ing 40 € 16 640 €
Riesgos surgidos desde la empresa subcontratada Contr-C 50 € 0 0€
Demoras en los trámites de las peticiones Adm-R 15 € 8 120 €
Demoras en la instalación por problemas técnicos Inst-Act; Op-R 35 € 40 1.400 €
Tabla 48: Recursos y costos de los riesgos de alta prioridad

Sobre la cantidad de presupuesto total estimada para la gestión de los riesgos

prioritarios, aunque se trate de una estimación con un cierto nivel de confianza, cabe
mencionar algunas aclaraciones:
• La cantidad total que figura en la tabla anterior es únicamente referencial,
debido a que hasta en tres de los riesgos principales, las horas que se dedicarán
son el promedio de un amplio rango de posibilidades que pueden cambiar
notoriamente el monto total.
• En esta cantidad no se contempla la posibilidad que a medida que el proyecto
vaya avanzando y se vayan realizando más sondeos de riesgos, puedan aparecer
(o también desaparecer) otros riesgos de alta prioridad.
• La estimación tampoco contempla la posibilidad (aunque muy baja) que se tenga
que hacer frente a los riesgos categorizados como de mediana o baja prioridad, o
también a riesgos secundarios.
• El total de presupuesto calculado para la gestión de riesgos no será incluido
directamente en el presupuesto del proyecto de migración de tecnologías, sino
que se trata únicamente de una cifra referencial.
La razón por la que se realizó el análisis de tiempo y gastos para la gestión de los
riesgos prioritarios es sólo para dar una idea concreta de lo que puede llegar a costar a la
administración del proyecto el hacer frente a los riesgos de alta prioridad. El verdadero
presupuesto que se incluirá para la gestión de los riesgos y en general para la gestión del

170
proyecto, además del presupuesto inicial estimado, es el margen adicional máximo de
presupuesto que se estimó en el análisis cuantitativo de los riesgos, y en el que se
incluyó información más completa del entorno de la ejecución y de los riesgos del
proyecto para obtener resultados más realistas y concluyentes.

171
CAPÍTULO 10: SIMULACIÓN DE EJECUCIÓN

10.1 INTRODUCCIÓN:

En el presente capítulo se mostrará un estudio previo al proceso real de ejecución del

proyecto, en el cual se ha realizado una simulación de ejecución de las actividades
programadas en la estructura de subdivisión del trabajo del proyecto para los primeros
días. El objetivo de la realización de dicha simulación es el de presentar un análisis
detallado de cómo se efectuará la gestión del proyecto cuando se encuentre en la fase de
ejecución, con la finalidad de poder dar una visión más completa y realista de cómo será
la evolución de los gastos a lo largo del tiempo, así como el uso de los plazos y recursos
asignados a cada actividad. En este capítulo se incluye además un breve análisis de
previsión al futuro cercano de la continuación de la ejecución del proyecto en función
de los avances registrados en la simulación, seguido de las respectivas conclusiones que
se pueden extraer de los resultados obtenidos.

Cabe resaltar que la presente simulación es de características completamente diferentes

a la simulación de Monte Carlo realizada en el capítulo anterior, debido a que para la
simulación de Monte Carlo se han de tener en cuenta toda la información posible sobre
los daños que puedan causar los riesgos en la ejecución del proyecto para tener una idea
concisa de hasta qué punto pueden los riesgos llegar a variar las previsiones de
ejecución del proyecto en rubros como la duración y el tiempo. En el caso de la presente
simulación no se tendrá en cuenta toda la información de riesgos porque se desea
simular un entorno realista en el que no todos los riesgos llegan a ocurrir, además que se
incluye también los efectos de las respuestas a los riesgos. Cabe hacer además la
aclaración que en presente capítulo no son tratados los temas del grupo del proceso de
ejecución sino únicamente de un análisis y perspectiva de una posible ejecución del
proyecto de migración en un entorno realista.

10.2 GENERACIÓN DE LA SIMULACIÓN:

10.2.1 Información previa:

La idea de la simulación es la de obtener una cantidad de resultados de ejecución

suficientes para analizar el progreso del desarrollo del proyecto y poder además obtener
información de previsiones sobre el futuro del proyecto en los aspectos de tiempo y
presupuesto. Para ello se ha simulado la ejecución de los cincuenta primeros días útiles
del desarrollo del proyecto, que equivalen a las diez primeras semanas del mismo. En el
estudio de planificación y distribución de los gastos en el tiempo, el periodo de análisis
fueron las semanas, y ello se mantendrá en la gestión de la ejecución, para analizar la
evolución del proyecto.

El rango de los primeros cincuenta días de ejecución abarca en el cronograma inicial de

la planificación, desde la primera actividad de la WBS que es la reunión de lanzamiento
del proyecto, hasta la actividad de ID 44, que es el análisis de los resultados de los
clientes tras la migración con ampliación en la fase de prueba piloto. Concretamente el
rango de simulación comprenderá desde el día Lunes 3 de Mayo hasta el Viernes 9 de
Julio del 2010. Ello significa que el análisis de los cincuenta primeros días de la

172
simulación abarcarán prácticamente las dos primeras fases de ejecución del proyecto, y
todos los resultados obtenidos sobre la previsión del futuro del proyecto son aplicables
para la tercera fase, de migración del resto de la red.

10.2.2 Presentación de los resultados:

La simulación se ha efectuado con la ayuda de la herramienta CC-Pulse, introduciendo

toda la información de planificación del proyecto y diversas consideraciones expuestas
en los apartados previos de planificación. El cronograma obtenido de los primeros
cincuenta días de ejecución presentado a continuación en la siguiente gráfica:

Gráfico 17: Fechas, duraciones y costos de las actividades simuladas

173
Entre las principales consideraciones que se tuvieron para simular de la manera más real
posible la ejecución del proyecto se encuentran los rangos mínimos y máximos que
pueden tomar las duraciones de cada actividad en función de su distribución
probabilística, además de las características de cada actividad en particular, y el historial
previo de actividades similares. Esto incluye además los rangos de los costos de cada
tarea, con las mismas consideraciones que en la duración; entre ambos aspectos
conforman la inclusión de la posibilidad de ocurrencia del riesgo por excesos en el
tiempo y/o presupuesto máximo previsto. Se incluyó también la posibilidad de que se
generen costos adicionales en algunas tareas debido a riesgos de demoras por problemas
técnicos en la ejecución, y sobre las cuales cabe recordar que dichos costos adicionales
de respuesta a la amenaza únicamente incluyen las horas de los responsables del riesgo
en aplicar la respuesta. Respecto al riesgo por posibles demoras en los trámites de
peticiones, se excluyeron de la simulación los márgenes adicionales de tiempo que se
pusieron luego de las tareas de peticiones externas. Ello se debe a que si luego de una
petición se previó una semana de espera de la respuesta, y la respuesta llegó tras tres
días, los otros dos días restantes se suprimen y continúan las actividades programadas
para después de la petición. Y en tal caso, los tres días de espera se consideran como
parte de la duración de la actividad de petición, y para ello se pusieron rangos de tiempo
adecuados.

10.3 ANÁLISIS DE LOS RESULTADOS:

Al observar el cronograma con los resultados de la simulación de ejecución una vez

obtenidos, se puede pensar ‘a priori’ que son muy pocas las actividades que se
ejecutaron y finalizaron según los parámetros previstos, pero que aún así las primeras
semanas del proyecto en líneas generales no han salido demasiado diferentes de lo
previsto. Antes de poder extraer más conclusiones sobre el pasado y futuro del proyecto
a partir del punto de análisis establecido en cincuenta días, se pasará estudiar y
comparar la información obtenida en rubros separados de tiempo y presupuesto, con
diversas técnicas y fórmulas que se expondrán en los siguientes apartados.

10.3.1 Análisis general de los resultados:

El primer punto a resaltar del cronograma de las actividades ejecutadas en la simulación

es que figuran 43 de las 44 actividades planificadas para las diez primeras semanas, lo
que lleva a pensar que el proyecto ha sufrido un ligero retraso conjunto. Dicho retraso
no se refleja muy bien en la duración total del proyecto debido a que este último pasó de
197,5 días a 197,94 días, y las actividades de ID 43 y 44 están pensadas de realizarse en
al menos 4,5 y 3 días respectivamente. Para obtener más información sobre los tiempos
y gastos de ejecución en los primeros días, el primer paso para el análisis de los
resultados generales de la simulación será la división y comparación de los datos por
semanas.

En el apartado de planificación se estableció el periodo de medición de gastos al

término de cada semana, por lo que ya se pude establecer una relación con los gastos
semanales planificados. Dicha lista de gastos semanales previstos se puede comparar
entonces con los respectivos gastos simulados distribuidos por semana en las tablas a
continuación:

174
 Semana 1 2 3 4 5
Planificación 1.595,00 € 2.450,00 € 970,00 € 1.240,00 € 1.600,00 €
Simulación 1.657,50 € 2.012,50 € 1.912,50 € 1.070,00 € 1.906,25 €

Semana 6 7 8 9 10
Planificación 1.340,00 € 460,00 € 800,00 € 800,00 € 1.435,00 €
Simulación 1.108,75 € 1.150,00 € 830,00 € 800,00 € 1.277,50 €
Tabla 49: Gastos semanales de la simulación

Tras la comparación numérica de los gastos, únicamente en uno de los diez puntos de
medición semanal, en la novena semana concretamente, se encuentra que los gastos
planificado y simulado son iguales. Del resto de puntos se puede ver que hay algunos
gastos que a pesar de haber salido mayores o menores, están muy cerca de lo
planificado, como es el caso de las semanas 1, 8 o 10. Existen otros puntos en los que la
diferencia de gastos es más acentuada, como en las semanas 3, 5 o 7. Con la siguiente
simulación se tienen diez puntos de medición, los cuales ya son suficientes como para
extraer conclusiones y previsiones de futuro. Entonces, para tener una impresión más
clara de las diferencias de los gastos por semana, en el gráfico a continuación se muestra
el flujo de gastos semanal de la ejecución, comparado respecto a las diez primeras
semanas de la línea base de medición del presupuesto:

Gráfico 18: Flujo de gastos semanales de la simulación

Ahora se puede apreciar mejor el efecto de la ejecución en el flujo de gastos del

proyecto, el cual tiene sus puntos más dispares en las semanas 2, 3 y 7. Debido a la
forma del flujo en las primeras semanas de la simulación, en la que la primera semana
es muy similar a la planificada, pero en la segunda hay un bajón que en cierta forma
contrasta con un exceso en la tercera semana, se puede pensar que ha habido atrasos en
las primeras actividades ejecutadas. Dicha hipótesis se refuerza porque la línea base
planificada tiene puntos mínimos en las semanas 3 y 7, pero la simulación presenta

175
mínimos en las semanas 4 y 9, lo que sugiere un atraso general en las primeras
actividades de la WBS del proyecto.

Además de posibles atrasos en el cronograma del proyecto, se desea saber el estado del
gasto general del proyecto, debido a que en la presentación de los resultados de la
simulación, y a diferencia de la duración total del proyecto que no fue muy diferente a
la prevista, el presupuesto sí tiene una diferencia algo más notoria, de 68’598 € respecto
a los 67’191 € estimados. El primer paso entonces será la revisión del total de los gastos
efectuados en las primeras semanas, y para ello se presenta el siguiente gráfico en donde
se representa las diferencias de los gastos planificados y simulados por semana:

Gráfico 19: Diferencia de gastos semanales simulados respecto a planificados

Las diferencias positivas indican un mayor gasto al previsto, y en general se producen

diferencias amplias de gastos en tres de las diez semanas, que son la 2, 3, y 7, y en
ningún caso una amplia diferencia se mantiene en dos semanas consecutivas. Es posible
que los excesos de gastos en las semanas 3 y 7 estén relacionados con las probables
demoras detectadas en la gráfica de flujo de gastos.

De todas maneras, el área bajo la gráfica en la zona positiva (gris claro) es claramente
mayor al área de la zona inferior al eje central (gris oscuro), lo cual indica que el
proyecto ha gastado más presupuesto en las primeras diez semanas respecto a lo
previsto. Para poder examinar dicho exceso de presupuesto con datos numéricos se
presentan los valores de los gastos acumulados por semana en las siguientes tablas:

Semana 1 2 3 4 5
Planificación 1.595,00 € 4.045,00 € 5.015,00 € 6.255,00 € 7.855,00 €
Simulación 1.657,50 € 3.670,00 € 5.582,50 € 6.652,50 € 8.558,75 €

Semana 6 7 8 9 10
Planificación 9.195,00 € 9.655,00 € 10.455,00 € 11.255,00 € 12.690,00 €
Simulación 9.667,50 € 10.817,50 € 11.647,50 € 12.447,50 € 13.725,00 €
Tabla 50: Gastos semanales acumulados de la simulación

176
Las cifras de la última semana confirman que se ha gastado más de lo previsto en los
primeros cincuenta días, dado que la ejecución excede en 1’035 € a los 12’690 €
estimados para este primer periodo del proyecto. Este exceso no es únicamente visible
en la última semana, sino de una manera continua en la mayoría de semanas del
proyecto, a excepción del inicio, lo cual confirma los indicios de exceso de gastos. La
idea de que se produjeron varios retrasos pequeños en las tareas, se apoya en que si los
tiempos y gastos van cambiando de una manera similar, es poco probable que dichos
excesos en ambos aspectos se den por razones puntuales o no relacionadas entre sí. A
continuación se propone una gráfica con los valores acumulados de los gastos para la
visualización de la evolución temporal de las diferencias de gastos:

Gráfico 20: Evolución de los gastos totales de la simulación

La evolución de los gastos presenta cifras casi iguales en la primera semana, lo cual
cambia y los gastos para la segunda semana son menores que lo previsto; esto
concuerda con el primer mínimo grande en la gráfica de diferencia de gastos. A partir de
la tercera semana en adelante, se ve un aumento progresivo de las diferencias, pero en
este caso siendo mayores los gastos de ejecución. El cambio de diferencias entre la
segunda y tercera semana se debe al primer máximo grande en la gráfica de diferencia
de gastos. Una vez ha ocurrido dicho cambio, en ninguna semana los gastos acumulados
han logrado bajar hasta lo previsto, sino ir en aumento hasta llegar a los 13’725 €, o lo
que es lo mismo, un 8,15% a más de lo esperado.

10.3.2 Análisis temporal de los resultados:

A pesar de ser desveladas las características generales de los resultados generados, se

presume que el análisis aplicado no ha sido suficiente para saber cuáles fueron las
causas por las que los resultados tomaron dichas formas. Entonces se pasará al siguiente
nivel del análisis, en el que se estudian los resultados con las actividades terminales de
la WBS como puntos de referencia, y ello se hará separando los rubros de tiempo y
presupuesto para alcanzar un mayor nivel de detalle.

177
El primer ámbito a analizar será el tiempo, cuya unidad se normalizó para todas las
actividades en horas. Antes de mostrar la información de duraciones para cada
actividad, cabe mencionar que las tres últimas, de ID 42, 43 y 44, no serán información
útil de análisis debido a que ninguna ha finalizado en las diez primeras semanas. En el
caso de las tareas 42 y 43, comenzaron con retraso pero su ejecución quedó detenida
con el fin de la simulación, mientras que la tarea 44, no llegó ni a comenzar. La razón
que esta última actividad quedó fuera del cronograma obtenido en la simulación fue por
no tener fecha de inicio en el plazo válido. Dichos datos no formarán parte de los datos
a estudiar porque el agregar en el análisis costos y duraciones incompletos de una tarea
se interpretarían como completos, y ello puede cambiar los resultados de los análisis
sobre la simulación. De todas maneras debido a que tanto la fecha planificada de inicio
de esta tarea como las de las tareas 42 y 43 están dentro del plazo inicial, se mostrarán
indicadas dichas tareas en la tabla a continuación:

ID Tarea Planificación Simulación

2 Reunión de lanzamiento del proyecto 5 horas 6 horas
4 Listado de clientes con HFC 5 horas 4,5 horas
5 Análisis de la red HFC 32 horas 34 horas
6 Análisis de la red SDH 16 horas 14 horas
7 Análisis de la central de conmutación 16 horas 14 horas
8 Informe de estado inicial 8 horas 12 horas
9 Definición de la prueba piloto 8 horas 8 horas
11 Reunión de lanzamiento de la prueba piloto 8 horas 8 horas
13 Comunicación inicial con los clientes 12 horas 14 horas
15 Configuración de la central de conmutación 1 hora 1,25 horas
16 Configuración del acceso 8 horas 8 horas
18 Generación de scripts de conmutación 1 hora 1 hora
19 Generación de scripts de acceso 7 horas 6,5 horas
20 Migración de líneas 72 horas 96 horas
22 Desconfiguración de la central de conmutación 2 horas 2 horas
23 Desconfiguración del acceso 2 horas 2,25 horas
24 Comunicación final con los clientes 12 horas 8 horas
27 Solicitud de permiso de actuación para instalación 5 horas 4 horas
28 Solicitud de material 5 horas 4 horas
29 Pedido de reposición de material 2 horas 1 hora
30 Instalación y activación de equipos adicionales 100 horas 110 horas
31 Comunicación inicial con los clientes 12 horas 16 horas
33 Configuración de la central de conmutación 16 horas 18 horas
34 Configuración del acceso 8 horas 8 horas
36 Generación de scripts de conmutación 5 horas 7 horas
37 Generación de scripts de acceso 6 horas 5 horas
38 Migración de líneas 104 horas 104 horas
40 Desconfiguración de la central de conmutación 2 horas 3 horas
41 Desconfiguración del acceso 2 horas 3 horas
42 Comunicación final con los clientes 12 horas 8,5 horas
43 Análisis de resultados de la red 30 horas 11 horas

178
 44 Análisis de resultados de los clientes 5 horas 0 horas
Tabla 51: Duraciones planificadas y resultantes de las tareas simuladas

Son pocas las actividades que se han ejecutado según el tiempo previsto, pero en
aspectos generales las duraciones simuladas no han variado demasiado. De todas
maneras, la mayor parte de las actividades con tiempos desfasados se tratan de retrasos,
lo cual es la razón que explica que se tengan las tres últimas actividades previstas sin
finalizar, mientras que en el cronograma de planificación la actividad de ID 42 estaba
estimada para finalizarse dentro del mismo plazo, y las otras dos actividades deberían
haber sido empezadas. Para comprender mejor qué actividades han contribuido a
incrementar o disminuir la demora general en la ejecución, se muestra el siguiente
gráfico con las duraciones planificada y simulada para cada tarea terminal finalizada de
la WBS del proyecto con su respectivo ID asociado:

Gráfico 21: Duraciones planificadas y resultantes de las tareas simuladas

Cada una de las actividades de corta o mediana duración, aunque estén repartidos entre
retrasos, igualdades o anticipos a la fecha prevista de finalización, tienen tiempos de
ejecución muy similares a los planificados. Las diferencias significativas vienen dadas
por las demoras en la ejecución de algunas de las actividades de larga duración, por las
de ID 20 y 30 concretamente. Se puede afirmar entonces que se debe tener especial
atención en las actividades de larga duración que en este caso son las cercanas y
mayores a las 50 horas. En este grupo se clasifican las actividades de ID 20, 30 y 38, las
cuales se tratan de actividades con alta complejidad técnica, que son la migración de las
líneas y la instalación y activación de los equipos adicionales. Lo más probable en este
tipo de tareas es que ocurran demoras por problemas técnicos, sobre todo en las
primeras, debido a que si se repite la misma actividad en el futuro, ya se cuenta con la
experiencia y documentación del personal técnico para acelerar los trabajos y evitar que
se repitan los mismos contratiempos que sufrieron al inicio. Esta puede ser la razón por
la que no ha habido más retrasos en la tercera actividad de larga duración, de ID 38, que
además es la repetición de la previa actividad similar de ID 20, que presenta el mayor
retraso de todas las actividades ejecutadas. Entre la actividad 20 y 30, con retrasos de 24

179
y 10 horas respectivamente, suman un total de 34 horas de retraso, lo que supone
teóricamente 4,25 días en demoras, casi una semana laborable entera. La demora
perceptible es menor porque ambas actividades 20 y 30 no se ejecutan una después de la
otra sino casi en paralelo, con lo que el retraso total perceptible en el cronograma del
proyecto es menor. En la gráfica a continuación de duración acumulada de las tareas, se
tendrá una mejor idea de la influencia de estas demoras en el total de la gestión de
tiempos en la ejecución:

Gráfico 22: Acumulado de duraciones por tareas simuladas

En dicha gráfica se confirma lo que se mencionaba anteriormente sobre la influencia de

las largas demoras en la duración total de las tareas ejecutadas. Hasta antes de la
actividad de ID 20 se observan que los tiempos planificados y ejecutados van muy
similares, pero luego de dicha actividad se percibe una diferencia notoria que se
mantiene hasta la tarea de ID 30, en donde luego se vuelve a incrementar y se mantiene
relativamente hasta el final de la misma. La suma de todas las horas trabajadas en todas
las actividades hasta la de ID 41 es de 522,5 horas, mientras que la suma de todas las
horas estimadas asciende a las 482 horas, lo que representa un 8,4% a más en la
ejecución. No se debe confundir esta suma de duraciones de tareas con los tiempos
reales del cronograma, en los que la tarea de ID 41 estaba planificada de finalizarse el
día Jueves 8 de Julio del 2010, y su ejecución finalizó al día siguiente. Ello supone un
cambio en el cronograma, que las tareas finalizadas hasta la de ID 41 pasan de requerir
49 a abarcar 50 días útiles, lo cual significa un 2% a más sobre los plazos de ejecución
del proyecto hasta la tarea 41 respecto a lo previsto.

El otro motivo por el que el cronograma obtenido del proyecto no ha tenido una demora
similar respecto a la demora general de las actividades ejecutadas, sino notoriamente
menor, se debe a que se han aplicado satisfactoriamente los márgenes de tiempos de
contingencia sobre las tareas que eran precedidas por tiempos de espera inciertos debido
a trámites externos o comunicación con clientes. En el caso de la tarea de ID 20 se tenía
programada una duración de 72 horas que pasó en la ejecución a 96 horas en total, ello
se debe a que en dicha duración está además incluido el margen de espera previo a la

180
ejecución de la tarea, que en este caso era de 5 días útiles. En el cronograma obtenido de
la ejecución ya no figura esta semana de espera previa a la tarea 20, pero sí la demora de
ejecución como parte de la duración de la tarea. La inclusión de la espera real en la
duración de la tarea no se aplica para las esperas por trámites. Dentro del plazo de los
cincuenta primeros días estaban previstos dos márgenes de tiempo para comunicación
con clientes para las actividades de ID 20 y 38, y uno más para trámites externos antes
de la actividad de ID 30, que en total suman 17 días. Estos tres márgenes generan al
cronograma del proyecto una espera total menor a los 17 días al no tratarse de
actividades secuenciales. Luego de la ejecución, el margen de 5 días pasó a una demora
de 3 días para la tarea 20, en cuya duración están incluidas además las demoras por
motivos técnicos. La espera por trámites de la tarea 30 pasó de 5 + 2 días (esperas luego
de la finalización de las tareas 27 y 28 respectivamente) a 7 + 2 días, además de una
demora de 1,25 días adicionales por temas técnicos. En el caso de la tarea 38, los 5 días
de margen se redujeron en su totalidad y la ejecución de la actividad no presentó
demoras respecto a lo previsto.

10.3.3 Análisis presupuestal de los resultados:

De la misma manera que en ámbito de las duraciones, los costos de las actividades
terminales de la WBS del proyecto que se ejecutaron, han obtenido valores similares a
los estimados, aunque en muy pocos casos han sido los mismos. Debido a que las tres
últimas actividades de ID 42,43 y 44 no se terminaron de ejecutar, en el caso de la
última ni empezó, y por las mismas razones expuestas en el apartado anterior, en este
caso tampoco pasarán a formar parte de los datos a analizar. De todas maneras, sí se
presentan dichas actividades en la siguiente tabla con la información sobre los costos
planificados y ejecutados para las actividades terminales finalizadas en el plazo de
simulación de ejecución:

ID Tarea Planificación Simulación

2 Reunión de lanzamiento del proyecto 600,00 € 720,00 €
4 Listado de clientes con HFC 75,00 € 67,50 €
5 Análisis de la red HFC 640,00 € 680,00 €
6 Análisis de la red SDH 320,00 € 280,00 €
7 Análisis de la central de conmutación 320,00 € 280,00 €
8 Informe de estado inicial 320,00 € 480,00 €
9 Definición de la prueba piloto 960,00 € 960,00 €
11 Reunión de lanzamiento de la prueba piloto 1.080,00 € 1.080,00 €
13 Comunicación inicial con los clientes 180,00 € 210,00 €
15 Configuración de la central de conmutación 20,00 € 25,00 €
16 Configuración del acceso 160,00 € 160,00 €
18 Generación de scripts de conmutación 20,00 € 20,00 €
19 Generación de scripts de acceso 140,00 € 130,00 €
20 Migración de líneas 1.440,00 € 2.060,00 €
22 Desconfiguración de la central de conmutación 40,00 € 40,00 €
23 Desconfiguración del acceso 40,00 € 45,00 €
24 Comunicación final con los clientes 180,00 € 120,00 €
27 Solicitud de permiso de actuación para instalación 75,00 € 60,00 €
28 Solicitud de material 75,00 € 60,00 €

181
 29 Pedido de reposición de material 30,00 € 15,00 €
30 Instalación y activación de equipos adicionales 2.000,00 € 2.375,00 €
31 Comunicación inicial con los clientes 180,00 € 240,00 €
33 Configuración de la central de conmutación 320,00 € 360,00 €
34 Configuración del acceso 160,00 € 160,00 €
36 Generación de scripts de conmutación 100,00 € 140,00 €
37 Generación de scripts de acceso 120,00 € 100,00 €
38 Migración de líneas 2.080,00 € 2.080,00 €
40 Desconfiguración de la central de conmutación 40,00 € 60,00 €
41 Desconfiguración del acceso 40,00 € 60,00 €
42 Comunicación final con los clientes 180,00 € 127,50 €
43 Análisis de resultados de la red 600,00 € 220,00 €
44 Análisis de resultados de los clientes 75,00 € 0,00 €
Tabla 52: Gastos planificados y resultantes de las tareas simuladas

El hecho de tener las tres mismas actividades con los costos en la misma distribución
que las duraciones, y que en este caso todas los gastos están directamente
proporcionados con las duraciones de sus respectivas actividades confirma que la
ejecución del proyecto en la simulación ha sufrido de un ligero retraso y aumento de
gastos que al menos en parte están relacionados. De las dos actividades de larga
duración que tenían márgenes previos de espera por comunicación con clientes, se
comentó que en su duración ejecutada se incluían las demoras reales por espera. Para
dichas actividades de ID 20 y 38, las demoras reales incluyen los respectivos costos de
la propia actividad, debido a que en ese plazo se considera dentro de la actividad,
además de tener a los recursos de la actividad asignados a la misma durante todo ese
tiempo. Para una mejor idea de cómo resultaron los gastos por cada tarea respecto a lo
planificado, se muestra la gráfica de gastos por tareas presentada a continuación:

Gráfico 23: Gastos planificados y resultantes de las tareas simuladas

182
Lo primero en destacar al mirar la gráfica de gastos por tareas es que de manera similar
a la gráfica de duración por tareas, tanto las actividades de bajo como de mediano costo
tienen un gasto de ejecución similar al estimado, mientras que en el caso de las
actividades de alto costo, en este caso también las de ID 20 y 30, presentan un amplio
exceso respecto a lo previsto. Sobre estas dos actividades de alto costo en particular,
cabe mencionar que parte del exceso de su costo de ejecución se debe a la aplicación de
respuestas a riesgos de demoras por motivos técnicos. En el caso de la actividad 20, se
tuvo que hacer una reunión de 4 horas entre los responsables del riesgo para analizar las
causas y determinar la respuesta necesaria. Dicha reunión elevó en 140 € el monto del
costo total de la actividad, que ascendió hasta los 2’060 €. Para la actividad 30 también
se tuvo que realizar una reunión por parte de los responsables del riesgo que duró 5
horas, y aumentó los gastos de la actividad en 175 € para llegar a un total de 2’375 €. Al
aplicar satisfactoriamente la respuesta al riesgo en la actividad 20, dicho proceso se
documentó y utilizó como referencia en la ejecución de la actividad 38 al ser similar a la
20, que en su caso no se produjeron riesgos. A continuación se muestra una gráfica con
los valores de gastos acumulados por tareas terminales ejecutadas y finalizadas:

Gráfico 24: Acumulado de gastos por tareas simuladas

Tal y como se dedujo por los resultados anteriores, se comprueba que la evolución de
los gastos por actividad están directamente proporcionados con la evolución de la
duración de las actividades. El progreso de los gastos se mantiene muy cerca de los
montos estimados desde la primera tarea hasta la de ID 20, en donde hay que recordar
que se produce una demora por tiempo de espera y un gasto adicional por gestión de
riesgos técnicos. A partir de esa actividad, los gastos del proyecto se empiezan a
diferenciar notoriamente de lo planificado, y luego se produce un segundo aumento en
la evolución de los gastos en la tarea 30, en donde se produce una demora de ejecución
y otro gasto adicional por riesgos técnicos. Luego, la suma de gastos por actividades
ejecutadas y finalizadas asciende a 13’067,50 € respecto a los 11’755 € previstos, lo que
genera un exceso de gastos del 11,16% hasta la actividad 41. Este porcentaje es
diferente al obtenido en el análisis general de los resultados debido a que no incluye los

183
gastos por las actividades sin finalizar, debido a que ya se mencionó que su inclusión en
el análisis por actividades interpretaría dichos gastos parciales como finales, y cambiaría
el porcentaje real de diferencia de gastos totales por actividad.

En total los gastos directos por riesgos ascienden a los 315 €, aumentando más los
gastos generales. Sin dichos gastos por riesgos, el exceso de gastos totales hasta la
actividad 41 sería del 8,4%, sin tomar en cuenta las posibles repercusiones de los
riesgos de no tratarse y llegar a ocurrir. La diferencia entre los efectos de los gastos y las
duraciones es que la gestión de riesgos a efectos prácticos ha incrementado en un 2,76%
los gastos totales (o disminuido según se valoren los posibles impactos de ocurrir dichos
riesgos), mientras que con la aplicación de márgenes de contingencia para las esperas
previas a las actividades de larga duración se ha logrado reducir la demora en el
cronograma general de ejecución del proyecto.

10.4 GESTIÓN DEL VALOR OBTENIDO:

El Earned Value Management o gestión del valor obtenido, es una técnica de gestión de
proyectos muy útil para planificar, analizar, controlar y predecir progresivamente la
evolución de la ejecución de un proyecto. Se basa en el constante feedback o
retroalimentación con nueva información para la actualización de sus resultados. Sus
resultados sirven para saber y controlar el estado del proyecto en los apartados de
alcance, cronograma y presupuesto.

Para su correcta aplicación, las técnicas y criterios de medición de datos para cada tarea
son fundamentales y han sido planificados en el apartado de gestión del proyecto, así
como además la distribución del presupuesto para cada tarea y un nivel adecuado de
jerarquía en la WBS del proyecto para posibilitar análisis detallados del progreso sin
comprometer un exceso de tareas ni del control a ejercer. Una vez establecida también
la OBS, asignados los responsables a las actividades de la WBS, y secuenciadas las
tareas con fechas, duraciones y presupuesto, se pudo extraer la línea base de medición
de la ejecución que es la pieza fundamental para la gestión del valor obtenido. La PMB
se estableció con puntos de medición semanales y las mismas magnitudes que la
evolución de los gastos por motivos de simplicidad; su representación gráfica se
encuentra en el apartado de gestión de costos del capítulo de planificación.

10.4.1 Presentación de los elementos básicos del EVM:

Los elementos básicos sobre los que se basa el análisis de gestión del valor obtenido
vienen dado por tres conceptos, que son el Planned Value, Earned Value y Actual Cost,
los cuales tienen valores numéricos. Luego de la simulación de los primeros cincuenta
días, se presentan dichos elementos con sus respectivos resultados obtenidos:
• Planned Value (PV): Representa el valor planificado del desarrollo del proyecto
en un punto dado de la ejecución. Su valor para el fin de la décima semana de
ejecución es de 12’690.
• Earned Value (EV): Se entiende por valor obtenido a aquella cifra que
representa el progreso del trabajo realizado hasta el momento de medición. Su
valor en la presente ejecución es de 12’050,08.
• Actual Cost (AC): Indica el presupuesto gastado en el trabajo real realizado
hasta el momento de la medición. Su valor resultante es de 13’415,30.

184
Cabe recordar que los tres valores son acumulados de los puntos de medición (en
semanas). La evolución de dichos valores en la simulación ha sido la siguiente:

Semana Planned Value Earned Value Actual Cost

1 1595,00 1550,29 1657,50
2 4045,00 3437,49 3670,00
3 5015,00 5281,15 5608,25
4 6255,00 6126,67 6758,14
5 7855,00 7533,26 8538,93
6 9195,00 8415,03 9511,31
7 9655,00 9393,67 10687,64
8 10455,00 10235,17 11517,72
9 11255,00 11035,17 12317,72
10 12690,00 12050,08 13415,30

La información en la tabla confirma la diferencia entre los tres valores. La evolución del
trabajo ejecutado es muy similar al planificado, pero casi siempre inferior, que era de
suponer al confirmase en los análisis previos que las actividades tuvieron un ligero
retraso general. Se confirma además según lo visto anterior, que hubo ligeros excesos de
gastos debido a los retrasos en las actividades ejecutadas, al ver que el acumulado de los
gastos del trabajo completado (AC) es mayor al mismo trabajo completado (EV), y en
algunos casos, mayor también al desarrollo planificado (PV). En la siguiente gráfica se
representa la progresión semanal de los tres valores en la ejecución de la simulación:

Gráfico 25: Comparación del desarrollo del proyecto respecto a la línea base

185
Los valores del trabajo realizado y de los gastos únicamente se mantienen casi iguales a
lo planificado en la primera semana, debido a que en la segunda ya se encuentran por
debajo de lo previsto. Si el Valor Obtenido se encuentra por debajo de lo planificado,
significa que hay retrasos, ya sean producidos o acumulados, mientras que si se
encuentra al mismo nivel que el Valor Planificado, quiere decir que las tareas se
ejecutan según lo previsto. En el caso de la tercera semana, el Valor Obtenido se
encuentra por encima del Valor Planificado, lo que quiere decir que se realizó más
trabajo del planificado hasta la fecha, y en este caso en concreto, representa el adelanto
en la fecha de ejecución de la actividad 20, y por lo tanto, un cierto adelanto relativo en
el cronograma del proyecto. A partir de la cuarta semana en adelante, el Valor Obtenido
es siempre menor y el Costo Actual mayor, pero ambos siempre cercanos al Valor
Planificado y evolucionando de maneras similares.

Antes de pasar a la realización del análisis del proyecto con las herramientas del EVM
se define un cuarto elemento necesario para dicho análisis, y se trata del Budget At
Completion (BAC) o presupuesto al término del proyecto. Este elemento es un valor
que representa la cantidad final de presupuesto planificado con la que se estima finalizar
el proyecto. Para el presente caso de ejecución el valor del BAC es de 67’191 €.

10.4.2 Análisis del desempeño con EVM:

El análisis del desempeño obtenido en la ejecución de la simulación con el EVM se basa

en la utilización de ciertas definiciones y fórmulas para extraer datos numéricos sobre el
desarrollo del proyecto que responden a ciertas preguntas en concreto sobre el
desempeño. El primer aspecto de estudio de la ejecución es el temporal, que se realiza
obteniendo los siguientes valores:
• Schedule Variance (SV): Responde a la pregunta de ¿Vamos por delante o detrás
del calendario?, su fórmula y valor obtenido para la presente ejecución son:

SV = EV – PV = 12’050,08 – 12’690 = -639,92

El valor negativo del resultado indica que efectivamente la ejecución va por

detrás de lo previsto en el calendario del proyecto. Para tener una mejor
referencia del retraso del calendario respecto a lo planificado se calcula el SV
sobre el valor planificado:

SV(%) = SV / PV = -639,92 / 12’690 = -5,04%

El resultado es un porcentaje que apunta a que el proyecto va retrasado en un

5,04% respecto a lo planificado, o lo que es lo mismo, que un 5,04% del trabajo
planificado no se ha realizado.
• Schedule Performance Index (SPI): Responde a la pregunta de ¿Qué tan
eficientemente se está utilizando el tiempo?, su fórmula y valor obtenido para la
presente ejecución son:

SPI = EV / PV = 12’050,08 / 12’690 = 0,95

Por lo tanto se puede afirmar que el tiempo asignado para el proyecto se está
utilizando con una eficiencia del 95%.

186
El retraso porcentual total obtenido con las herramientas del EVM es del 5%, mientras
que en el análisis temporal de los resultados por actividad, la demora total no superó el
2%. Esta diferencia se debe a que en análisis anterior se tomaron en cuenta únicamente
las actividades ejecutadas y finalizadas en el plazo estudiado, mientras que en este
análisis se cuentan todas las tareas programadas para el plazo.

Luego de vistas las consecuencias de la ejecución en el aspecto temporal, el siguiente

aspecto del análisis con las herramientas del EVM es el presupuestal, en el que de
manera similar se responderán preguntas para saber el estado de los gastos de la
ejecución en la décima semana de simulación. Los valores que responden a las
preguntas presupuestales son los siguientes:
• Cost Variance (CV): Responde a la pregunta de ¿Estamos por encima o por
debajo del presupuesto estimado?, su fórmula y valor obtenido para la presente
ejecución son:

CV = EV – AC = 12’050,08 – 13’415,30 = -1’365,22

El valor absoluto del resultado se interpreta en este caso en euros, y su signo

negativo indica que se ha gastado más de lo previsto en la realización del trabajo
hecho hasta la fecha. Para saber la diferencia de gastos respecto a lo planificado,
se calcula la varianza relativa de costos:

CV(%) = CV / EV = -1365,22 / 12’050,08 = -11,33%

Entonces, el porcentaje de gastos obtenido indica que se ha gastado un 11,33% a

más de lo planificado hasta la fecha de medición. El signo negativo entonces
hace referencia a un exceso en los gastos, lo que se interpreta como algo
negativo o no deseado para el proyecto.
• Cost Performance Index (CPI): Responde a la pregunta de ¿Cuán eficientemente
se está utilizando el presupuesto?, su fórmula y valor obtenido para la presente
ejecución son:

CPI = EV / AC = 12’050,08 / 13’415,30 = 0,89

Se responde entonces a la pregunta planteada afirmando que se está utilizando el

presupuesto del proyecto con una eficiencia del 89%.

Los porcentajes de eficiencia son notoriamente diferentes en ambos aspectos del análisis
no sólo por su valor sino porque la eficiencia temporal se encuentra dentro del margen
de tiempo adicional asignado, mientras que la eficiencia de gastos escapa su respectivo
margen adicional. Es muy probable que este factor conlleve a cambios en la gestión de
costos, para lo cual se tendrá que revisar más al detalle las razones por las que se dieron
dichos valores.

10.4.3 Predicción del desarrollo con EVM:

Una vez conocidas las características de la ejecución, se pueden realizar predicciones

sobre el futuro del desarrollo del proyecto en base dicha información. De la misma
manera que en el análisis del desempeño de la ejecución, la predicción del desarrollo
con EVM se realizará separando los aspectos de tiempo y presupuesto. La predicción se

187
basa también en la obtención de resultados numéricos a través de fórmulas que sean
capaces de responder a preguntas clave sobre el futuro del proyecto. En el aspecto
temporal se tiene:
• Time Estimate at Completion (EACt): Responde a la pregunta de ¿Para cuándo
se estima finalizar el trabajo?, su fórmula y valor obtenido para la presente
ejecución son:

EACt = (BAC / SPI) / (BAC / Tproyecto)

EACt = (67’191 / 0,95) / (67’191 / 40) = 42,12

El valor de Tproyecto ingresado en la fórmula es la cantidad de semanas previstas

inicialmente para la finalización del proyecto. El resultado tiene entonces como
unidad las semanas, e indica que si se sigue al mismo ritmo de trabajo realizado
en el período de ejecución analizado, el proyecto tardará un total de 42,12
semanas para terminar.

Si se toma en cuenta el tiempo total del proyecto incluyendo el margen adicional

asignado del 10,4%, se tiene un rango de hasta 44,16 semanas para poder finalizar el
proyecto sin problemas, lo cual confirma que el aspecto temporal marcha dentro de los
plazos previstos. Cabe recordar que para el presente proyecto el aspecto temporal es
justamente el más importante de ambos, porque las restricciones con las que cuenta no
dependen ni del proyecto ni tampoco de la empresa. En el caso del presupuesto, si éste
requiriese algo más de lo previsto, se puede estudiar la posibilidad y optar a ello.

La predicción con EVM del aspecto presupuestal responde a más preguntas sobre el
futuro del proyecto que el aspecto temporal debido a que consta de más conceptos y
fórmulas para su estudio, las cuales se presentan a continuación:
• To-Complete Performance Index (TCPI): Responde a la pregunta de ¿Con qué
eficiencia se deberá utilizar el presupuesto restante?, su fórmula y valor obtenido
para la presente ejecución son:

TCPI = (BAC - EV) / (BAC - AC)

TCPI = (67’191 – 12’050,08) / (67’191 – 13’415,30) = 1,02

El resultado con valor mayor a 1 indica que se deberá gastar menos de lo

previsto para las tareas que quedan, para poder llegar al final del proyecto
habiendo gastado lo planificado. En este caso, la eficiencia es muy cercana a 1,
debido a que la diferencia en los gastos hasta la fecha no fue excesivo, además
de que aún falta por ejecutarse 30 de las 40 semanas del proyecto.
• Estimate at Completion (EAC): Responde a la pregunta de ¿Cuánto costaría todo
el proyecto?, su fórmula y valor obtenido para la presente ejecución son:

EAC = BAC / CPI = 67’191 / 0,89 = 74’803,44

Evidentemente la unidad del resultado está en euros, y representa el monto del

presupuesto total que acabaría costando todo el proyecto en caso que se siga
trabajando con mismo ritmo de gastos que en la simulación.

188
 • Variance at Completion (VAC): Responde a la pregunta de ¿Acabaremos por
encima o por debajo del presupuesto estimado?, su fórmula y valor obtenido
para la presente ejecución son:

VAC = BAC – EAC = 67’191 – 74’803,44 = -7’612,44

El valor absoluto de la respuesta indica la diferencia entre el supuesto gasto final

y el gasto planificado, y el signo negativo representa que se terminaría gastando
más de lo previsto, lo cual supone un aspecto negativo para la gestión del
proyecto. Su valor comparado al del presupuesto inicial se define y calcula de la
siguiente manera:

VAC(%) = VAC / BAC = -7’612,44 / 67’191 = -11,33%

El resultado porcentual es el mismo que el CV(%), debido a que por definición

la relación de gastos se mantiene en ambas, pero lo único que cambia es el rango
de tiempo analizado.
• Estimate to Complete (ETC): Responde a la pregunta de ¿Cuánto costaría el
trabajo restante?, su fórmula y valor obtenido para la presente ejecución son:

ETC = (BAC - EV) / CPI = (67’191 - 12’050,08) / 0,89 = 61’388,14

Indica la cantidad de presupuesto que queda por gastar si el ritmo de gastos en la

ejecución se mantuviese invariable. Para tener una idea, en el caso de la
planificación lo que quedaría por gastar ascendería a 55’140,92 € para las 30
semanas restantes.

Luego de analizados los datos de la simulación y predicho el futuro del proyecto, se

puede concluir que la gestión del tiempo en las diez primeras semanas ha sido la
suficientemente como para mantener al proyecto dentro de los plazos previstos. Para los
gastos en cambio, se ha visto que se están excediendo más de lo previsto, y que si no se
toman medidas y se sigue al mismo ritmo, el presupuesto máximo no alcanzaría. El
objetivo para la administración del proyecto por ende debe de ser el de intentar
gestionar los gastos para que evolucionen según el TCPI o más, con la finalidad de
poder acabar el proyecto sin mayores excesos presupuestales a los permitidos.

189
CAPÍTULO 11: CONCLUSIONES

El análisis y la aplicación de las cinco nuevas extensiones del libro del PMBOK sobre
un proyecto real de telecomunicaciones ha hecho posible apreciar en magnitudes reales
y con un nivel de detalle adecuado que los conceptos y metodologías planteados para la
gestión de proyectos facilita esta finalidad y hace posible la consecución de grandes
resultados de la manera más óptima posible.

En el apartado de los capítulos teóricos, en líneas generales se puede asegurar

rotundamente que el WBS es la herramienta más útil y básica sobre la que se estructura
y guía la planificación de un proyecto. Sobre los métodos de aplicación de esta
herramienta son remarcables la regla del 100%, los dos principios de calidad, y los
métodos de creación. Como respuesta a la necesidad surgida de un ordenamiento
temporal del proyecto y sus respectivas tareas cronológicamente, surge la planificación
del itinerario, que definitivamente es el segundo gran paso para lograr completar la
planificación. Es muy importante recordar que el itinerado del proyecto promueve la
estructuración de los recursos para su asignación a las tareas, y la sucesión entre las
mismas antes de asignar duraciones. Es además útil la utilización de las técnicas PERT
y CPM para los tiempos de las actividades, y el establecimiento de una línea base para
la planificación y seguimiento del desarrollo.

La gestión de riesgos se presenta como una de las extensiones más detalladas en la que
las metodologías para la planificación son fundamentales para asegurar el éxito en la
consecución de los objetivos. El establecimiento de criterios comunes para la gestión es
el primer punto importante, seguido de las técnicas para la detección y clasificación de
riesgos, y el método de Monte Carlo como el método de análisis de riesgos. Como
consecuencia a la planificación del itinerario y establecimiento de la línea base de
desempeño, el libro de la gestión del valor obtenido aborda uno de los estándares más
interesantes para la gestión general del proyecto durante su ejecución. La cuantificación
de la carga de trabajo realizado y el presupuesto utilizado en diversos puntos de la
ejecución son medibles y comparables con la línea base. Éste estándar resulta
importante a la hora de responder a preguntas vitales sobre el análisis del desempeño del
proyecto y predecir su futuro basándose en simples fórmulas matemáticas.

Respecto a la implementación de los nuevos estándares prácticos al proyecto de

migración de tecnologías, el nivel de detalle de la WBS propuesto en el presente
proyecto es algo simplificado respecto al caso real debido que a efectos prácticos, desde
el punto de vista de la gestión es más adecuado y manejable para el logro de los
objetivos de este proyecto. Sin embargo, si se hubiese profundizado en otras áreas de
conocimiento como calidad, recursos humanos, o comunicación, es probable que se
haya debido manejar mayor detalle, aunque ello suponga una carga notablemente mayor
de planificación, seguimiento, e integración.

Un gran inconveniente del secuenciado de actividades al momento de la planificación

fue que la tercera fase de la migración no se pudo programar para empezar
paralelamente con la segunda fase como se deseaba inicialmente, debido a que la
segunda fase es una prueba necesaria para la viabilidad de la migración posterior en los
demás sectores. Si se diese el caso que se ejecuten ambas fases simultáneamente, y
luego de finalizada la prueba piloto se determina que el proyecto finalmente no es

190
viable, las pérdidas de tiempo, recursos y presupuestos invertidas en la tercera fase
hubiesen sido muy significativas. El principal compromiso en el diseño del itinerario
estuvo dado entre estas razones, y el tiempo mayor de cronograma que supone que la
tercera fase se ejecute luego de la segunda, pero con el beneficio en el balance final de
este compromiso que de determinarse el proyecto no viable luego de la prueba piloto,
las pérdidas respecto al primer escenario serían considerablemente menores.

La asignación de márgenes de tiempo posterior a actividades con una alta incertidumbre

en su duración o con un tiempo de espera incierto es una técnica de gran utilidad pero
que supone un compromiso: Agregar un margen de tiempo es introducir directamente
una demora fija en el proyecto desde su planificación, y no siempre un proyecto dispone
del tiempo adicional para esperar. La utilidad de la técnica radica en que al agregar un
margen de tiempo determinado mayor a lo esperado, se elimina la incertidumbre de la
espera, y de ocurrir una espera real menor, se adelantarían las ejecuciones de todas las
actividades posteriores. Este escenario puede asumirse como un adelanto, pero en
realidad no deja de ser un retraso acortado, por lo que es recomendable que además se
tomen medidas previas para que el tiempo de espera real disminuya.

La detección y clasificación de los riesgos fue el primer diagnóstico de las carencias del
proyecto a ser tomando en cuenta por la administración, y la toma de decisiones para las
respuestas, y las limitaciones por recursos, tiempo y presupuesto conformaron otro
compromiso más para el proyecto. La documentación previa sobre riesgos similares, la
opinión de los expertos en el tema, las prioridades del proyecto y los patrocinadores
terminaron siendo determinantes para poder distinguir a los riesgos de los que se darán
respuesta de los que no.

La simulación de Monte Carlo reveló que es muy probable que el proyecto pueda
excederse ligeramente del tiempo y/o presupuesto previsto, por lo que se incluyeron
márgenes de tiempo y presupuestos adicionales. Es por ello además que un factor clave
para mantener controlada la ejecución del proyecto es el mantener controlados los
riesgos de alta prioridad.

En la simulación de ejecución quedó demostrado que el proyecto es muy propenso a

sufrir ciertos retrasos y excesos en los gastos. Una de las razones fue que las pequeñas
demoras generalizadas en el promedio de las actividades supusieron un promedio de
gastos ligeramente excedidos respecto a lo planificado. Se demostró además que es muy
probable la ocurrencia de pequeños problemas técnicos supongan además de demoras y
gastos por demoras, montos adicionales para responder al riesgo, y contingencias a las
ocurrencias del riesgo. La utilización de los márgenes de tiempo adicionales fue útil a
pesar de lo estudiado porque en este caso el retraso que generaron en el cronograma de
planificación del proyecto no lo retrasó hasta fuera de la fecha límite. De todas maneras
dicha técnica se hace más útil cuando la prioridad es el presupuesto sobre el
cronograma, en caso de contar con restricciones presupuestales.

La aplicación de la gestión del valor obtenido sobre los resultados de la simulación de

las 10 primeras semanas terminó de confirmar la tendencia de las pequeñas demoras en
el proyecto, y el consecuente exceso en los gastos. Las fórmulas sobre el desempeño de
los 50 primeros días de ejecución muestran que a pesar de las demoras, se está
evolucionando dentro del margen de tiempos planificados; pero en el caso del
presupuesto, sí que se ha excedido ligeramente del rango máximo. Como consecuencia

191
de ello, las fórmulas de previsión a futuro indican que no se requieren mayores cambios
en el apartado del tiempo para terminar dentro de lo previsto. No ocurre lo mismo en el
caso del presupuesto, en la que los resultados apuntan a que si no se toman medidas
para reconducir la tendencia excesiva de gastos, se terminará gastando más de lo que se
pueda asumir.

Cabe recordar además que el principal factor limitante del proyecto es el tiempo, del
que prácticamente no se puede agregar más días adicionales porque la fecha límite ya
rozando la fecha en que la empresa proveedora descatalogará los equipos HFC y la
directiva de la empresa operadora pretende acabar el servicio de telefonía con HFC. En
el caso del presupuesto, se mencionó que a pesar de haber demostrado necesitar un 8%
adicional de margen, se puede aspirar hasta el 10%. De todas maneras, si se requiriese
algo más de presupuesto, ya sea menor o mayor al 10%, se deberá demostrarlo a la
directiva de la empresa. Se concluye entonces que el único ámbito del proyecto que
corre cierto riesgo de excedencia es el presupuesto, por lo que se deberá tomar medidas
contra ello, pero de todas maneras no es una limitante fija. En cualquier caso la
recomendación luego de analizadas las primeras diez semanas, es que la gestión del
proyecto deberá centrar sus esfuerzos en reducir los gastos y mantener el ritmo de
ejecución del cronograma para alcanzar los objetivos.

192
CAPÍTULO 12: LÍNEAS FUTURAS

La aplicación de las principales metodologías de las extensiones ha quedado demostrada

en este proyecto individual, pero queda por demostrar qué nivel de utilidad tendrían
para un entorno multi-proyecto, ya sea en programas o portafolios, y la variabilidad de
sus características en estos casos. Un claro ejemplo sería poner en práctica el segundo
principio de calidad del WBS, el cual sustenta que su aplicación y características deben
de ser invariables ante la magnitud del alcance.

En un proyecto de telecomunicaciones real, una de los principales objetivos es casi

siempre obtener resultados finales de calidad, ya sean productos o servicios, debido que
se trata de un sector tecnológico. Es por ello que la gestión de un proyecto de
telecomunicaciones no debería quedar exenta de la planificación y control en el área de
conocimiento de calidad. El desarrollo de un estándar práctico que ocupe estos aspectos
beneficiaría enormemente a este y otros sectores basados en tecnología. Además, en los
proyectos de sectores tecnológicos y de gran envergadura, un gran inconveniente es la
gran carga de trabajo que supone la constante recolección e integración de datos para
analizar la evolución del proyecto. Es por ello que sería interesante que se puedan
desarrollar nuevos mecanismos de control del desempeño que permitan examinar el
avance del proyecto de manera más sencilla y rápida. Una posible solución sería el
desarrollo de software que permitiese medir o ingresar los datos de ejecución de cada
actividad en términos de tiempo, recursos, riesgos y costos para analizar el desarrollo
del proyecto, en el mejor de los casos, en tiempo real.

Luego de vista la tendencia que está tomando la empresa operadora para la evolución de
su red y mejora en los servicios ofrecidos, una probable línea de continuidad sería que
más adelante esta tendencia termine convergiendo en la migración final de toda la red
hacia una misma tecnología más avanzada que permita el ofrecimiento de todos los
servicios que ofrece la empresa con mejores prestaciones. Cabe recordar que esta misma
tendencia ya ha sido probada por otras empresas en la integración a base de nuevas
tecnologías para ofrecer servicios de telefonía fija e internet, o internet y telefonía
móvil, entre otros.

La simulación de Monte Carlo es una herramienta que en cierta forma no da una

impresión completa de lo que podría pasar en el proyecto, dado que para obtener
resultados únicamente se toma en cuenta cierta información de variabilidad en las
duraciones de las actividades, del cronograma, en los costos, y de algunos riesgos. Una
posible mejora de esta herramienta sería que permitiese en general la inclusión de un
mayor nivel de detalle de información sobre todo lo que pueda afectar al desarrollo del
proyecto. Un ejemplo es que se tenga en cuenta datos como los resultados apreciables
de las respuestas a los riesgos en los ámbitos de medición, la aplicación de planes de
contingencia en caso de que ocurriesen, la posibilidad de ocurrencia de riesgos no tan
mesurables y sus consecuencias tangibles, incluir posibilidades de cancelación del
proyecto, entre otros.

En el ámbito de gestión de recursos, se puede también desarrollar mecanismos para que

optimice la utilización de los recursos en la medida de lo posible, abarcando casos como
la reasignación y compartición de los recursos de los que dispone el proyecto, y
maximizar el rendimiento de cada uno. La utilidad de estos mecanismos sería mayor

193
además en el sentido que una utilización óptima de recursos puede conllevar a
consecuencias beneficiosas para el proyecto como reducción de gastos por recursos y
reducción de tiempos de espera por recursos.

Una última línea de futuro sobre los mecanismos para facilitar la gestión de proyectos
viene dado por una posible mejora en la evaluación de la información en la gestión del
valor obtenido. El EVM está diseñado para medir la evolución del trabajo realizado
respecto al planificado, la evolución de los gastos respecto a lo planificado, y la
tendencia del proyecto en términos de tiempo, alcance, y costos. Pero muchas veces lo
que un administrador de proyecto necesita saber directamente, es el ritmo al que se
están alcanzando los objetivos del proyecto. La información obtenida de alcance
describe la carga de trabajo realizada, pero no necesariamente ello supone que el
objetivo se está alcanzando al mismo ritmo. Se podría entonces establecer una segunda
línea base de medición del proyecto en función a la importancia de cada actividad para
la consecución de objetivos, o de porcentaje real de objetivos logrados, para su posterior
seguimiento.

194
BIBLIOGRAFÍA

La bibliografía consultada para facilitar el desarrollo del presente Proyecto de Final de

Carrera, entre libros y referencias web, son:
• Project Management Institute – “A Guide to the Project Management Body of
Knowledge (PMBOK Guide), Fourth Edition” – PMI, 2004.
• Project Management Institute – “Practice Standard for Work Breakdown
Structures, Second Edition” – PMI, 2006.
• Project Management Institute – “Practice Standard for Scheduling” – PMI,
2007.
• Project Management Institute – “Practice Standard for Project Configuration
Management” – PMI, 2007.
• Project Management Institute – “Practice Standard for Project Risk
Management” – PMI, 2009.
• Project Management Institute – “Practice Standard for Earned Value
Management” – PMI, 2005.
• Kerzner, H. – “Project Management: A System’s Approach to Planning,
Scheduling, and Controlling” – Van Nostrand Reinhold Press, 2000.
• Haugan, Gregory T. – “Effective Work Breakdown Structures” VA
Management Concepts, 2002.
• [Link]
• [Link]
• [Link]

195
GLOSARIO

1. INCLUSIONES Y EXCLUSIONES:

Este glosario incluye términos que:

• Son propios, o prácticamente propios, de la dirección de proyectos (por ejemplo,
enunciado del alcance del proyecto, paquete de trabajo, estructura de desglose
del trabajo, método del camino crítico).
• No son propios de la dirección de proyectos, pero se usan de una forma diferente
o con una acepción más concreta en este ámbito que en el uso cotidiano y
general (por ejemplo, fecha de inicio temprana, actividad del cronograma).

En general, este glosario no incluye:

• Términos específicos de un área de aplicación (por ejemplo, prospecto del
proyecto como documento legal, propio del ámbito del desarrollo inmobiliario).
• Términos cuyo uso en la de dirección de proyectos no difiere en forma
sustancial del uso diario (por ejemplo, día calendario, retraso).
• Términos compuestos cuyo significado se deduce claramente de la combinación
de sus componentes.
• Variantes, cuando el significado de la variante se deduce claramente del término
básico (por ejemplo, se incluye informe por excepción, pero no presentación de
informes por excepción).

Como consecuencia de las inclusiones y exclusiones anteriores, este glosario contiene:

• Una cantidad preponderante de términos relativos a la Gestión del Alcance del
Proyecto, la Gestión del Tiempo del Proyecto y la Gestión de Riesgos del
Proyecto, dado que muchos de los términos usados en estas áreas son propios, o
prácticamente propios, de la dirección de proyectos.
• Muchos términos de Gestión de la Calidad del Proyecto, dado que se usan de
una manera más concreta que en la vida cotidiana.
• Relativamente pocos términos relacionados con la Gestión de los Recursos
Humanos del Proyecto y la Gestión de las Comunicaciones del Proyecto, dado
que la mayoría de los términos usados en estas áreas de conocimiento no
difieren mucho del uso diario.
• Relativamente pocos términos relacionados con la Gestión de los Costes del Proyecto,
Gestión de la Integración del Proyecto y la Gestión de las Adquisiciones del Proyecto,
dado que muchos de los términos usados en estas áreas de conocimiento tienen
significados concretos que son propios de un área de aplicación en particular.

2. SIGLAS COMUNES:

AC Actual Cost / Coste Real

ACWP Actual Cost of Work Performed / Coste Real del Trabajo Realizado
AD Activity Description / Descripción de la Actividad
ADM Arrow Diagramming Method / Método de Diagramación con Flechas
AE Apportioned Effort / Esfuerzo Prorrateado
AF Actual Finish date / Fecha de Finalización Real

196
AOA Activity-on-Arrow / Actividad en la Flecha
AON Activity-on-Node / Actividad en el Nodo
AS Actual Start date / Fecha de Inicio Real
BAC Budget at Completion / Presupuesto hasta la Conclusión
BCWP Budgeted Cost of Work Performed / Coste Presupuestado del Trabajo Realizado
BCWS Budgeted Cost of Work Scheduled / Coste Presupuestado del Trabajo
Planificado
BOM Bill Of Materials / Lista de Materiales
CA Control Account / Cuenta de Control
CAP Control Account Plan / Plan de la Cuenta de Control
CCB Change Control Board / Comité de Control de Cambios
COQ Cost of Quality / Coste de la Calidad
CPF Cost-Plus-Fee / Coste Más Honorarios
CPFF Cost-Plus-Fixed-Fee / Coste Más Honorarios Fijos
CPI Cost Performance Index / Índice de Rendimiento del Coste
CPIF Cost-Plus-Incentive-Fee / Coste Más Honorarios con Incentivos
CPM Critical Path Method / Método del Camino Crítico
CPPC Cost-Plus-Percentage of Cost / Coste Más Porcentaje del Coste
CV Cost Variance / Variación del Coste
CWBS Contract Work Breakdown Structure / Estructura de Desglose del Trabajo del
Contrato
DD Data Date / Fecha de los Datos
DU Duration / Duración
DUR Duration / Duración
EAC Estimate at Completion / Estimación a la Conclusión
EF Early Finish Date / Fecha de Finalización Temprana
EMV Expected Monetary Value / Valor Monetario Esperado
ES Early Start Date / Fecha de Inicio Temprana
ETC Estimate to Complete / Estimación hasta la Conclusión
EV Earned Value / Valor Ganado
EVM Earned Value Management / Gestión del Valor Ganado
EVT Earned Value Technique / Técnica del Valor Ganado
FF Finish-to-Finish / Final a Final
FF Free Float / Holgura Libre
FFP Firm-Fixed-Price / Precio Fijo Cerrado
FMEA Failure Mode and Effect Analysis / Análisis de Modos de Fallo y Efectos
FPIF Fixed-Price-Incentive-Fee / Precio Fijo Más Honorarios con Incentivos
FS Finish-to-Start / Final a Inicio
IFB Invitation for Bid / Invitación a Licitación
LF Late Finish date / Fecha de Finalización Tardía
LOE Level of Effort / Nivel de Esfuerzo
LS Late Start Date / Fecha de Inicio Tardía
OBS Organizational Breakdown Structure / Estructura de Desglose de la Organización
OD Original Duration / Duración Original
PC Percent Complete / Porcentaje Completado
PCT Percent Complete / Porcentaje Completado
PDM Precedence Diagramming Method / Método de Diagramación por Precedencia
PF Planned Finish Date / Fecha de Finalización Planificada
PM Project Management / Dirección de Proyectos
PM Project Manager / Director del Proyecto

197
PMBOK® Project Management Body of Knowledge / Fundamentos de la Dirección de
Proyectos
PMIS Project Management Information System / Sistema de Información de la Gestión
de Proyectos
PMO Program Management Office / Oficina de Gestión de Programas
PMO Project Management Office / Oficina de Gestión de Proyectos
PMP® Project Management Professional / Profesional de la Dirección de Proyectos
PS Planned Start Date / Fecha de Inicio Planificada
PSWBS Project Summary Work Breakdown Structure / Estructura de Desglose del
Trabajo del Proyecto Resumida
PV Planned Value / Valor Planificado
QA Quality Assurance / Aseguramiento de Calidad
QC Quality Control / Control de Calidad
RAM Responsibility Assignment Matrix / Matriz de Asignación de Responsabilidades
RBS Resource Breakdown Structure / Estructura de Desglose de Recursos
RBS Risk Breakdown Structure / Estructura de Desglose del Riesgo
RD Remaining Duration / Duración Restante
RFP Request for Proposal / Solicitud de Propuesta
RFQ Request for Quotation / Solicitud de Presupuesto
SF Scheduled Finish Date / Fecha de Finalización Planificada
SF Start-to-Finish / Inicio a Fin
SOW Statement of Work / Enunciado del Trabajo
SPI Schedule Performance Index / Índice de Rendimiento del Cronograma
SS Scheduled Start Date / Fecha de Inicio Planificada
SS Start-to-Start / Inicio a Inicio
SV Schedule Variance / Variación del Cronograma
SWOT Strengths, Weaknesses, Opportunities, and Threats / Debilidades, Amenazas,
Fortalezas y Oportunidades (DAFO)
TC Target Completion Date / Fecha de Conclusión Objetivo
TF Target Finish Date / Fecha de Finalización Objetivo
TF Total Float / Holgura Total
T&M Time and Material / Tiempo y Materiales
TQM Total Quality Management / Gestión de la Calidad Total
TS Target Start date / Fecha de Inicio Objetivo
VE Value Engineering / Ingeniería del Valor
WBS Work Breakdown Structure / Estructura de Desglose del Trabajo (EDT)

3. DEFINICIONES:

Muchas de las palabras definidas aquí tienen definiciones más amplias, y en algunos
casos distintas, en el diccionario.
Las definiciones utilizan las convenciones siguientes:
• Los términos que se utilizan como parte de las definiciones y que se definen en
el glosario aparecen en cursiva.
o Cuando el mismo término del glosario aparece más de una vez en una
definición determinada, sólo aparecerá en cursiva la primera vez.
o En algunos casos, un solo término del glosario comprende varias
palabras (por ej. planificación de la respuesta a los riesgos)

198
 o En muchos casos, hay términos múltiples y consecutivos de glosario en
una determinada definición. Por ejemplo, estimación de la duración
denota dos palabras distintas del glosario, “duración” y “estimación”.
o Incluso hay algunas definiciones con una serie de palabras consecutivas
en cursiva (que no están separadas por comas), que representan términos
múltiples y consecutivos del glosario, de los cuales, por lo menos uno,
consiste en palabras múltiples. Por ejemplo, Fecha de Finalización
Tardía del Método del Camino Crítico denota dos conceptos distintos del
glosario, “Método del Camino Crítico” y “Fecha de Finalización Tardía”.
En un caso como éste, aparecerá un asterisco (*) después de la última
palabra en cursiva de la serie, para denotar que hay varios términos del
glosario adyacentes.
• Cuando se incluyen sinónimos, no se da definición alguna y se dirige al lector al
término preferido (es decir, véase término preferido).
• Los términos relacionados que no son sinónimos se citan con referencias
cruzadas al final de la definición (es decir, véase también término relacionado).

En este glosario encontrará términos adicionales que no aparecen en la versión en

inglés. Como estos términos dependen de cada idioma, el glosario siguiente es en cierta
manera único. Los términos en castellano se corresponden con los usados en los
capítulos precedentes de esta publicación. Los otros términos usados frecuentemente
reflejan términos que se suelen usar en áreas específicas de la comunidad
hispanoparlante, y se proporcionan para ayudar al lector a asociar un término familiar
utilizado en una región al término utilizado en los capítulos anteriores. Estas entradas
del glosario siguen el formato estándar que aparece a continuación:
Término en Castellano / Término en Inglés; [Salida/Entrada o Herramienta/Técnica (si
es aplicable)]; Definición; También conocido como: otros términos usados
frecuentemente (si es aplicable, y en cursiva).

A la Fecha de / As-of Date. Véase fecha de los datos.

Acción Correctiva / Corrective Action. Directiva documentada para ejecutar el trabajo
del proyecto y poder, de ese modo, alinear el rendimiento futuro previsto del trabajo
del proyecto con el plan de gestión del proyecto.
Acción Preventiva / Preventive Action. Directiva documentada para realizar una
actividad que puede reducir la probabilidad de sufrir consecuencias negativas
asociadas con los riesgos del proyecto*.
Aceptación / Acceptance. Véase aceptar.
Aceptar / Accept. El acto de recibir o reconocer algo formalmente y considerarlo como
cierto, correcto, adecuado y completo.
Aceptar el Riesgo / Risk Acceptance [Técnica]. Una técnica de planificación de la
respuesta a los riesgos que indica que el equipo del proyecto ha decidido no cambiar
el plan de gestión del proyecto para hacer frente a un riesgo, o no ha podido
identificar alguna otra estrategia de respuesta adecuada. También conocido como:
Aceptación del Riesgo.
Acta de Constitución / Charter. Véase Project Charter. También conocido como: Acta
de Autorización.
Project Charter / Project Charter [Salida/Entrada]. Un documento emitido por el
iniciador o patrocinador del proyecto que autoriza formalmente la existencia de un
proyecto, y le confiere al director de proyectos la autoridad para aplicar los recursos
199
 de la organización a las actividades del proyecto. También conocido como: Acta de
Autorización del Proyecto; Acta de Proyecto; o Ficha del Proyecto.
Actividad / Activity. Un componente del trabajo realizado en el transcurso de un
proyecto. Véase también actividad del cronograma.
Actividad Casi Crítica / Near-Critical Activity. Una actividad del cronograma que tiene
una flotación total baja. El concepto de casi crítico es aplicable tanto a una actividad
del cronograma como a un camino de red del cronograma. El límite inferior al cual
la flotación total se considera casi crítica se encuentra sujeto al juicio de expertos y
varía de un proyecto a otro.
Actividad Crítica / Critical Activity. Cualquier actividad del cronograma en un camino
crítico del cronograma del proyecto. Se determina más comúnmente con el método
del camino crítico. Aunque algunas actividades son "críticas" en su sentido literal,
sin estar en el camino crítico, este significado se utiliza raramente en el contexto del
proyecto.
Actividad del Cronograma / Schedule Activity. Un componente del trabajo planificado
diferenciado realizado en el transcurso de un proyecto. Por lo general, una actividad
del cronograma tiene una duración estimada, un coste estimado y una estimación de
las necesidades de recursos. Las actividades del cronograma se conectan con otras
actividades del cronograma o hitos del cronograma mediante relaciones lógicas, y se
descomponen a partir de los paquetes de trabajo.
Actividad en el Nodo / Activity-On-Node (AON). Véase método de diagramación por
precedencia.
Actividad en la Flecha / Activity-On-Arrow (AOA). Véase método de diagramación con
flechas.
Actividad Ficticia / Dummy Activity. Una actividad del cronograma de duración cero,
que se usa para mostrar una relación lógica en el método de diagramación con
flechas. Las actividades ficticias se utilizan cuando las relaciones lógicas no se
pueden completar o describir correctamente con las flechas de la actividad del
cronograma. Las actividades ficticias generalmente se representan gráficamente
como una línea de puntos encabezada por una flecha.
Actividad Hammock / Hammock Activity. Véase actividad resumen. También conocido
como: Actividades Hamaca o Actividad Sumaria.
Actividad Predecesora / Predecessor Activity. La actividad del cronograma que
determina cuándo la actividad sucesora lógica puede comenzar o terminar.
Actividad Resumen / Summary Activity. Un grupo de actividades del cronograma
relacionadas, agregadas a algún nivel de resumen, que se muestran / informan como
una única actividad en un resumen. Véase también subproyecto y subred. También
conocido como: Actividad de Resumen o Actividad Sumaria.
Actividad Sucesora / Successor Activity. La actividad del cronograma que sigue a una
actividad predecesora, determinadas por su relación lógica.
Activos de los Procesos de la Organización / Organizational Process Assets
[Salida/Entrada]. Todos o cualquiera de los activos relacionados con los procesos,
de todas o alguna de las organizaciones involucradas en el proyecto, que se usan o
se pueden usar para ejercer una influencia sobre el éxito del proyecto. Estos activos
de los procesos incluyen planes formales e informales, políticas, procedimientos y
pautas. Los activos de los procesos también incluyen las bases de conocimiento de
las organizaciones tales como lecciones aprendidas e información histórica.
También conocido como: Activos de los Procesos Organizacionales.
200
Adelanto / Lead [Técnica]. Una modificación de una relación lógica que permite una
anticipación de la actividad sucesora. Por ejemplo, en una dependencia de final a
inicio con un adelanto de diez días, la
Glosario actividad sucesora puede comenzar diez días antes del fin de la actividad
predecesora. Véase también retraso. Un adelanto negativo es equivalente a un
retraso positivo.
Administración del Contrato / Contract Administration [Proceso]. El proceso de
gestionar el contrato y la relación entre el comprador y el proveedor, revisar y
documentar cuál es o fue el rendimiento de un proveedor a fin de establecer las
acciones correctivas necesarias y proporcionar una base para relaciones futuras con
el proveedor, gestionar cambios relacionados con el contrato y, cuando corresponda,
gestionar la relación contractual con el comprador externo del proyecto. También
conocido como: Administración de Contratos.
Adquirir el Equipo del Proyecto / Acquire Project Team [Proceso]. El proceso de
obtener los recursos humanos necesarios para realizar el proyecto. También
conocido como: Conformación Equipo del Proyecto; Conformar el Equipo de
Proyectos; o Reclutar el Equipo de Proyecto.
Alcance / Scope. La suma de productos, servicios y resultados que se proporcionarán
como un proyecto. Véase también alcance del proyecto y alcance del producto.
Alcance del Producto / Product Scope. Los rasgos y funciones que caracterizan a un
producto, servicio o resultado.
Alcance del Proyecto / Project Scope. El trabajo que debe realizarse para entregar un
producto, servicio o resultado con las funciones y características especificadas.
Amenaza / Threat. Una condición o situación desfavorable para el proyecto, conjunto de
circunstancias negativas, conjunto de eventos negativos, riesgo que si se hace
realidad tendrá un impacto negativo en un objetivo del proyecto, o posibilidad de
cambios negativos. Compárese con oportunidad.
Análisis Causal / Root Cause Analysis [Técnica]. Una técnica analítica utilizada para
determinar el motivo subyacente básico que causa una variación, un defecto o un
riesgo. Más de una variación, defecto o riesgo pueden deberse a una causa.
Análisis Cualitativo de Riesgos / Qualitative Risk Analysis [Proceso]. El proceso de
priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y
combinando la probabilidad de ocurrencia y el impacto.
Análisis Cuantitativo de Riesgos / Quantitative Risk Analysis [Proceso]. El proceso de
analizar numéricamente el efecto de los riesgos identificados en los objetivos
generales del proyecto.
Análisis de Asunciones / Assumptions Analysis [Técnica]. Técnica que analiza la
exactitud de las asunciones e identifica los riesgos del proyecto causados por el
carácter impreciso, incoherente o incompleto de las asunciones. También conocido
como: Análisis de Premisas; Análisis de Suposiciones; o Análisis de Supuestos.
Análisis de Debilidades, Amenazas, Fortalezas y Oportunidades (DAFO) / Strengths,
Weaknesses, Opportunities, and Threats (SWOT) Analysis. Esta técnica para
recabar información evalúa el proyecto desde la perspectiva de las fortalezas,
debilidades, oportunidades y amenazas de cada proyecto para aumentar la amplitud
de los riesgos considerados por la gestión de riesgos. También conocido como:
Análisis de Fortalezas, Oportunidades, Debilidades y Amenazas (FODA) o Análisis
de Fuerzas, Oportunidades, Debilidades y Amenazas.

201
Análisis de la Red / Network Analysis. Véase análisis de la red del cronograma.
Análisis de la Red del Cronograma / Schedule Network Analysis [Técnica]. 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. Véase también método del camino crítico, método de cadena crítica,
análisis de causa-efecto y nivelado de recursos.
Análisis de Modos de Fallo y Efectos / Failure Mode and Effect Analysis (FMEA)
[Técnica]. Un procedimiento analítico mediante el cual se analiza cada modo de
posible fallo en cada uno de los componentes de un producto, a fin de determinar
sus efectos sobre la fiabilidad de dicho componente y, por sí mismo o en
combinación con otros modos de posible fallo, sobre la confiabilidad del producto o
sistema y sobre la función requerida del componente; o el examen de un producto
(al nivel del sistema o en niveles inferiores) para detectar todas las formas en que se
puede producir un fallo. Para cada posible fallo, se realiza una estimación de sus
efectos sobre el sistema en su totalidad y de su [Link], se realiza
una revisión de las acciones planificadas para minimizar la probabilidad de los fallos
y para minimizar sus efectos. También conocido como: Análisis de Modo de Fallas
y Efectos.
Análisis de Reserva / Reserve Analysis [Técnica]. Una técnica analítica para determinar
las características y relaciones esenciales de los componentes en el plan de gestió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.
Análisis de Sensibilidad / Sensitivity Analysis. Una técnica de análisis cuantitativo de
riesgos y de modelado utilizada para ayudar a determinar qué riesgos tienen el
mayor impacto posible sobre el proyecto. Este método evalúa el grado 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.
Análisis de Tendencias / Trend Analysis [Técnica]. Una técnica analítica que utiliza
modelos matemáticos para pronosticar resultados futuros sobre la base de resultados
históricos. Es un método para determinar la variación respecto de la referencia de un
parámetro de presupuesto, coste, cronograma o alcance, en el que se utilizan datos
de períodos de informes de avance anteriores y se proyecta qué nivel puede alcanzar
la variación de dicho parámetro respecto de la referencia en un punto futuro del
proyecto si no se realizan cambios en la ejecución del proyecto.
Análisis de Variación / Variance Analysis [Técnica]. Un método para resolver la
variación total en el conjunto de variables de alcance, coste y cronograma en
variantes del componente específicas que están asociadas con factores definidos que
afectan las variables de alcance, coste y cronograma. También conocido como:
Análisis de Variaciones.
Análisis del Cronograma / Schedule Analysis. Véase análisis de la red del cronograma.
Análisis del Valor Monetario Esperado / Expected Monetary Value (EMV) Analysis.
Una técnica estadística que calcula el resultado promedio cuando el futuro incluye
escenarios que pueden ocurrir o no. Esta técnica se usa comúnmente dentro del
análisis del árbol de decisiones. Se recomienda el uso de modelos y la simulación
para el análisis de costes y riesgos del cronograma, porque es más efectivo y está
menos sujeto a errores de aplicación que el análisis del valor monetario esperado.

202
Análisis mediante Árbol de Decisiones / Decision Tree Analysis [Técnica]. El árbol de
decisiones es un diagrama que describe una decisión que se está considerando y las
consecuencias de seleccionar una u otra de las alternativas disponibles. Se usa
cuando algunos escenarios futuros o resultados de acciones son inciertos. Incorpora
las probabilidades y los costes o recompensas de cada camino lógico de eventos y
decisiones futuras, y usa el análisis del valor monetario esperado para ayudar a la
organización a identificar los valores relativos de las acciones alternativas. Véase
también análisis del valor monetario esperado.
Análisis Monte Carlo / Monte Carlo Analysis. Una técnica que calcula, o que repite, el
coste del proyecto o el cronograma del proyecto muchas veces, utilizando valores de
datos iniciales seleccionados al azar a partir de distribuciones de probabilidades de
costes o duraciones posibles, para calcular una distribución de los costes totales del
proyecto o fechas de conclusión posibles. También conocido como: Análisis de
Monte Carlo.
Aprobación / Approval. Véase aprobar.
Aprobar / Approve. El acto de confirmar, autorizar, ratificar o aceptar algo
formalmente.
Área de Aplicación / Application Area. Una categoría de proyectos que tienen
componentes significativos en común y que no están presentes ni son necesarios en
todos los proyectos. Por lo general, las áreas de aplicación se definen en términos
del producto (es decir, por tecnologías o métodos de producción similares) o del tipo
de cliente (es decir, interno contra externo, gubernamental contra comercial) o del
sector de la industria (es decir, servicios públicos, automoción, aeroespacial,
tecnologías de la información). Las áreas de aplicación pueden superponerse.
Área de Conocimiento de la Dirección de Proyectos / Project Management Knowledge
Area. Un área identificada de la dirección de proyectos definida por sus requisitos
de conocimientos y que se describe en términos de sus procesos de componentes,
prácticas, datos iniciales, resultados, herramientas y técnicas. También conocido
como: Área de Conocimiento de la Administración de Proyectos; Área de
Conocimiento de la Gerencia de Proyectos; Área de Conocimiento de la Gestión de
Proyectos; o Área de Conocimiento del Gerenciamiento de Proyectos.
Área de Conocimiento, Dirección de Proyectos / Knowledge Area, Project
Management. Véase Área de Conocimiento de Dirección de Proyectos. También
conocido como: Área de Conocimiento, Administración de Proyectos; Área de
Conocimiento, Gerencia de Proyectos; Área de conocimiento, Gerenciamiento de
Proyectos; o Área de Conocimiento, Gestión de Proyectos.
Asignación para Contingencias / Contingency Allowance. Véase reserva.
Asunciones / Assumptions [Salida/Entrada]. Las asunciones 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. Las asunciones afectan todos los
aspectos de la planificación del proyecto y son parte de la elaboración gradual del
proyecto. Los equipos del proyecto frecuentemente identifican, documentan y
validan las asunciones como parte de su proceso de planificación. Las asunciones
generalmente involucran un grado de riesgo. También conocido como: Premisas;
Suposiciones; o Supuestos.
Atributos de la Actividad / Activity Attributes [Salida/Entrada]. Varios atributos
asociados con cada actividad del cronograma que pueden incluirse dentro de la lista
de actividades. Entre los atributos de la actividad se pueden mencionar códigos de la
actividad, actividades predecesoras, actividades sucesoras, relaciones lógicas,

203
 adelantos y retrasos, requisitos de recursos, fechas impuestas, restricciones y
asunciones.
Autoridad / Authority. El derecho de aplicar recursos del proyecto*, gastar fondos,
tomar decisiones u otorgar aprobaciones.
Autorización de Trabajo / Work Authorization [Técnica]. Un permiso y directiva,
generalmente por escrito, para comenzar a trabajar en una actividad del cronograma,
paquete del trabajo o cuenta de control específica. Es un método para autorizar
trabajos del proyecto y garantizar que la organización identificada realice el trabajo
en el tiempo asignado y con la secuencia correcta.
Base de Conocimientos de Lecciones Aprendidas / Lessons Learned Knowledge Base.
Almacenamiento de información histórica y lecciones aprendidas, tanto acerca de
los resultados de decisiones de selección de proyectos anteriores como de
rendimiento de proyectos anteriores.
Base de Datos de Riesgos / Risk Database. Repositorio que permite la recogida, el
mantenimiento y el análisis de los datos recolectados y utilizados en los procesos de
gestión de riesgos.
Bienes / Goods. Productos básicos, artículos de comercio, mercancías.
Bucle de Red / Network Loop. Un camino de red del cronograma que pasa dos veces
por el mismo nodo. Los bucles de red no pueden analizarse con técnicas
tradicionales de análisis de la red del cronograma tales como el método del camino
crítico. También conocido como: Lazo de Red.
Calendario de Recursos / Resource Calendar. Un calendario de días laborales y no
laborales que determina aquellas fechas en las que cada recurso específico está
ocioso o puede estar activo. Por lo general, define festivos específicos de recursos y
períodos de disponibilidad de los recursos. Véase también calendario del proyecto.
Calendario del Proyecto / Project Calendar. Un calendario de días o turnos laborales que
establece las fechas en las cuales se realizan las actividades del cronograma, y de
días no laborales que determina las fechas en las cuales no se realizan las
actividades del cronograma. Habitualmente define los días festivos, los fines de
semana y los horarios de los turnos. Véase también calendario de recursos.
Calidad / Quality. El grado en el que un conjunto de características inherentes satisface
los requisitos.
Cambio en el Alcance / Scope Change. Cualquier cambio en el alcance del proyecto. Un
cambio en el alcance casi siempre requiere un ajuste en el coste o cronograma del
proyecto. También conocido como: Cambio del Alcance.
Cambio Solicitado / Requested Change [Salida/Entrada]. Una solicitud de cambio
formalmente documentada que se presenta para su aprobación al proceso de control
integrado de cambios. Compárese con solicitud de cambio aprobada. También
conocido como: Solicitud de Cambio.
Camino Crítico / Critical Path [Salida/Entrada]. Generalmente, pero no siempre, es la
secuencia de actividades del cronograma que determina la duración del proyecto.
Normalmente, es el camino más largo para el proyecto. No obstante, un camino
crítico puede finalizar, por ejemplo, en un hito delcronograma que se encuentra en el
medio del cronograma del proyecto y que tiene una restricción del cronograma
expresada por una fecha impuesta que exige finalizar antes de una fecha
determinada. Véase también método del camino crítico. También conocido como:
Ruta Crítica.

204
Camino de Red / Network Path. Cualquier serie continúa de actividades del cronograma
conectadas con relaciones lógicas en un diagrama de red de cronograma del
proyecto. También conocido como: Ruta de la Red.
Categoría de Riesgo / Risk Category. Un grupo de posibles causas de riesgo. Las causas
de riesgo pueden agruparse en categorías como técnica, externa, de la organización,
ambiental o de dirección de proyectos. Una categoría puede incluir subcategorías
como madurez técnica, clima o estimación agresiva. Véase también estructura de
desglose del riesgo.
Causa Común / Common Cause. Una fuente de variación que es inherente al sistema y
previsible. En un diagrama de control, aparece como parte de la variación de
proceso al azar (es decir, la variación de un proceso que se podría considerar normal
o no inusual) y se indica por medio de un patrón de puntos al azar dentro de los
límites de control. También se la conoce como causa al azar. Compárese con causa
especial.
Causa Especial / Special Cause. Una fuente de variación que no es inherente al sistema,
que no es previsible y que es intermitente. Se puede atribuir a un defecto en el
sistema. En un diagrama de control, es indicada por los puntos que exceden los
límites de control o por los patrones de puntos que no son al azar dentro de los
límites de control. También se la conoce como causa atribuible. Compárese con
causa común.
Centro de Mando / War Room. Una sala utilizada para las conferencias y planificación
del proyecto que, por lo general, tiene diagramas de los costes, de la situación del
cronograma y otros datos clave del proyecto. También conocido como: Cuarto de
Trabajo.
Cerrar Proyecto / Close Project [Proceso]. El proceso de finalizar todas las actividades
en todos los grupos de procesos del proyecto para cerrar formalmente el proyecto o
una fase de él. También conocido como: Cerrar el Proyecto o Cierre del Proyecto.
Ciclo de Vida / Life Cycle. Véase ciclo de vida del proyecto.
Ciclo de Vida del Producto / Product Life Cycle. Un conjunto de fases del producto*
que, generalmente, son secuenciales y sin superposición, cuyos nombres y números
son determinados por las necesidades de fabricación y control de la organización. La
última fase del ciclo de vida del producto es, generalmente, el deterioro y la muerte
del producto. Generalmente, un ciclo de vida del proyecto está contenido dentro de
uno o más ciclos de vida del producto.
Ciclo de Vida del Proyecto / Project Life Cycle. Un conjunto de fases del proyecto que,
generalmente son secuenciales, cuyos nombres y números son determinados por las
necesidades de control de la organización u organizaciones involucradas en el
proyecto. Un ciclo de vida puede ser documentado con una metodología.
Cierre del Contrato / Contract Closure [Proceso]. El proceso de completar y aprobar el
contrato, incluida la resolución de cualquier tema pendiente y el cierre de cada
contrato.
Cliente / Customer. La persona u organización que usará el producto, servicio o
resultado del proyecto. (Véase también usuario).
Código de Cuentas / Code of Accounts [Herramienta]. Todo sistema de numeración que
se utilice para identificar de forma única cada uno de los componentes de la
estructura de desglose del trabajo. Compárese con plan de cuentas .
Código de la Actividad / Activity Code. Uno o más valores numéricos o de texto que
identifican las características del trabajo o de alguna manera categorizan cada
205
 actividad del cronograma y que permiten filtrar y ordenar las actividades dentro de
los informes.
Colchón / Buffer. Véase reserva. También conocido como: Holgura o Reserva.
Comité de Control de Cambios / Change Control Board (CCB). Un grupo formalmente
constituido de interesados responsable de analizar, evaluar, aprobar, retrasar o
rechazar cambios al proyecto, y registrar todas las decisiones y recomendaciones.
Compensación / Compensation. Algo entregado o recibido, un pago o recompensa, por
lo general, monetaria o en especie por productos, servicios o resultados
proporcionados o recibidos.
Componente / Component. Una parte, elemento o pieza constitutiva de un todo
complejo.
Componente de la Estructura de Desglose del Trabajo / Work Breakdown Structure
Component. Una entrada en la estructura de desglose del trabajo que se puede
realizar en cualquier nivel. También conocido como: Componente de la Estructura
de Desagregación del Trabajo; Componente de la Estructura de Descomposición del
Trabajo; Componente de la Estructura de la División del Trabajo; Componente de la
Estructura Detallada de Trabajo; o Componente del Desglose de la Estructura del
Trabajo.
Comprador / Buyer. Persona que adquiere productos, servicios o resultados para una
organización.
Compresión del Cronograma / Schedule Compression [Técnica]. Reducción de la
duración del cronograma del proyecto sin disminuir el alcance del proyecto. Véase
también intensificación y seguimiento rápido.
Comunicación / Communication. Un proceso a través del cual se intercambia
información entre personas utilizando un sistema común de símbolos, signos o
comportamientos.
Conocimiento / Knowledge. Conocer algo con la familiaridad obtenida a través de la
experiencia, la educación, la observación o la investigación, comprender un proceso,
práctica o técnica, o cómo usar una herramienta.
Contingencia / Contingency. Véase reserva.
Contrato / Contract [Salida/Entrada]. Un contrato es un acuerdo vinculante para las
partes en virtud del cual el proveedor se obliga a proveer el producto, servicio o
resultado especificado y el comprador a pagar por él.
Contrato de Coste Más Honorarios con Incentivos / Cost-Plus-Incentive-Fee (CPIF)
Contract. Un tipo de contrato de costes reembolsables en el que el comprador
reembolsa al proveedor los costes permitidos correspondientes al proveedor (según
se define costes permitidos en el contrato) y el proveedor obtiene sus ganancias si
cumple los criterios de rendimiento definidos. También conocido como: Contrato de
Costo Más Honorarios con Incentivos o Contrato de Costos Más Honorarios con
Incentivos.
Contrato de Coste Más Honorarios Fijos / Cost-Plus-Fixed-Fee (CPFF) Contract. Un
tipo de contrato de costes reembolsables en el que el comprador reembolsa al
proveedor los costes permitidos correspondientes al proveedor (según se define
costes permitidos en el contrato) más una cantidad fija de ganancias (pago fijo).
También conocido como: Contrato de Costo Más Honorarios Fijos o Contrato de
Costos Más Honorarios Fijos.

206
Contrato de Costes Reembolsables / Cost-Reimbursable Contract. Un tipo de contrato
que implica el pago (reembolso) por parte del comprador al proveedor por los costes
reales del proveedor, más un honorario que, por lo general, representa la ganancia
del proveedor. Los costes son generalmente clasificados en directos e indirectos.
Los costes directos son aquellos que están exclusivamente vinculados al proyecto,
por ejemplo, salarios de los miembros del equipo con dedicación completa. Los
costes indirectos, también denominados gastos generales y costes administrativos y
generales, son costes asignados al proyecto por la organización ejecutante como
coste por hacer negocios como, por ejemplo, salarios de la gerencia indirectamente
involucrada en el proyecto y el coste de los servicios públicos eléctricos para la
oficina. Generalmente, los costes indirectos se calculan como un porcentaje de los
costes directos. Los contratos de costes reembolsables suelen incluir cláusulas de
incentivos en virtud de las cuales, si el proveedor cumple o supera los objetivos
seleccionados del proyecto, como ser metas del cronograma o coste total, entonces
el proveedor recibe del comprador un incentivo o pago de bonificación. También
conocido como: Contrato de Costos Reembolsables.
Contrato de Precio Fijo Cerrado / Firm-Fixed-Price (FFP) Contract. Un tipo de contrato
de precio fijo en el cual el comprador paga al proveedor un monto establecido
(conforme lo defina el contrato), independientemente de los costes del proveedor.
También conocido como: Contrato de Precio Fijo o Contrato de Precio Firme y Fijo.
Contrato de Precio Fijo Más Honorarios con Incentivos / Fixed-Price-Incentive-Fee
(FPIF) Contract. Un tipo de contrato en el cual el comprador paga al proveedor un
monto establecido (conforme lo defina el contrato), y el proveedor puede ganar un
monto adicional si cumple con los criterios de rendimiento establecidos. También
conocido como: Contrato de Precio Fijo más Incentivos.
Contrato de Precio Fijo o de Suma Global / Fixed-Price or Lump-Sum Contract. Un tipo
de contrato que implica un precio total fijo para un producto claramente definido.
Los contratos por un precio fijo también pueden incluir incentivos para quienes
cumplan o superen ciertos objetivos del proyecto seleccionados, tales como los
objetivos de cumplimiento del cronograma. La forma más simple de un contrato de
precio fijo es una orden de compra. También conocido como: Contrato de Precio
Fijo o de Precio Alzado.
Contrato por Tiempo y Materiales / Time and Material (T&M) Contract. Un tipo de
contrato que es un acuerdo contractual híbrido que contiene aspectos tanto de
contratos de costes reembolsables como de contratos de precio fijo. Los contratos
por tiempo y materiales se asemejan a los acuerdos de costes reembolsables en que
no tienen un final definido, porque el valor total del acuerdo no se define en el
momento de la adjudicación. Por tanto, los contratos por tiempo y materiales pueden
crecer en valor contractual como si fueran acuerdos del tipo de costes
reembolsables. Por otro lado, los acuerdos por tiempo y materiales también se
asemejan a los acuerdos de precio fijo. Por ejemplo, el comprador y el proveedor
establecen por anticipado las tarifas unitarias cuando las dos partes acuerdan una
tarifa para la categoría de ingenieros expertos.
Control / Controlling. Véase controlar. También conocido como: Controlando.
Control de Cambios / Change Control. Identificar, documentar, aprobar o rechazar y
controlar cambios en las líneas base del proyecto*.
Control de Costes / Cost Control [Proceso]. El proceso de influenciar los factores que
crean variaciones y controlar los cambios en el presupuesto del proyecto. También
conocido como: Control del Costo o Control de Costos.

207
Control del Alcance / Scope Control [Proceso]. El proceso de controlar los cambios en
el alcance del proyecto.
Control del Cronograma / Schedule Control [Proceso]. El proceso de controlar los
cambios del cronograma del proyecto.
Control Integrado de Cambios / Integrated Change Control [Proceso]. El proceso de
revisar todas las solicitudes de cambio, aprobar los cambios y controlar los cambios
a los productos entregables y a los activos de los procesos de la organización.
Controlar / Control [Técnica]. Comparar el rendimiento real con el rendimiento
planificado, analizar las variaciones, calcular las tendencias para realizar mejoras en
los procesos, evaluar las alternativas posibles y recomendar las acciones correctivas
apropiadas según sea necesario.
Convergencia de Caminos / Path Convergence. La fusión o unión de caminos de red de
cronogramas paralelos en un mismo nodo en un diagrama de red de cronograma del
proyecto. La convergencia de caminos se caracteriza por una actividad del
cronograma con más de una actividad predecesora. También conocido como:
Convergencia de Rutas.
Corrupción del Alcance / Scope Creep. Adición de funciones y funcionalidad (alcance
del proyecto) sin considerar los efectos sobre el tiempo, los costes y los recursos, o
sin la aprobación del cliente. También conocido como: Adiciones al Alcance;
Alteración del Alcance; o Cambio Mayor del Alcance.
Coste / Cost. El valor monetario o precio de una actividad o componente del proyecto*
que incluye el valor monetario de los recursos necesarios para realizar y terminar la
actividad o el componente, o para producir el componente. Un coste específico
puede estar compuesto por una combinación de componentes de coste, incluidas las
horas de mano de obra directa, otros costes directos, horas de mano de obra
indirecta, otros costes indirectos y precio de compra. (Sin embargo, en algunas
ocasiones, para la metodología de gestión del valor ganado, el término coste puede
referirse únicamente a horas de mano de obra sin su conversión al valor monetario).
Véase también coste real y estimación. También conocido como: Costo.
Coste de la Calidad / Cost of Quality (COQ) [Técnica]. Determinar los costes en los que
se incurre para garantizar la calidad. Los costes de prevención y evaluación (costes
de cumplimiento) incluyen costes de planificación de calidad, control de calidad y
aseguramiento de calidad para garantizar el cumplimiento de los requisitos (es decir,
capacitación, sistemas de control de calidad, etc.). Los costes de fallos (costes de no
cumplimiento) incluyen los costes de reprocesar productos, componentes o procesos
que no cumplen con los requisitos, los costes de la garantía del trabajo y
desperdicio, y la pérdida de reputación. También conocido como: Costo de la
Calidad.
Coste Más Honorarios / Cost-Plus-Fee (CPF). Un tipo de contrato de costes
reembolsables en el que el comprador reembolsó al proveedor los costes permitidos
correspondientes al proveedor por realizar el trabajo del contrato, y el proveedor
también recibió un honorario calculado como un porcentaje de los costes
previamente acordado. El honorario varía en función del coste real. También
conocido como: Costo Más Honorarios o Costos Más Honorarios.
Coste Más Porcentaje del Coste / Cost-Plus-Percentage of Cost (CPPC). Véase coste
más honorario. También conocido como: Costo Más Porcentaje del Costo.

208
Coste Presupuestado del Trabajo Planificado / Budgeted Cost of Work Scheduled
(BCWS). Véase valor planificado. También conocido como: Costo Presupuestado
del Trabajo Planificado o Costo Presupuestado del Trabajo Programado.
Coste Presupuestado del Trabajo Realizado / Budgeted Cost of Work Performed
(BCWP). Véase valor ganado. También conocido como: Costo Presupuestado del
Trabajo Realizado.
Coste Real / Actual Cost (AC). Costes totales realmente incurridos y registrados para
llevar a cabo un trabajo que se realizó en un período determinado respecto de una
actividad del cronograma o componente de la estructura de desglose del trabajo. En
ocasiones, los costes reales pueden ser horas de mano de obra directa únicamente,
costes directos únicamente o todos los costes, incluidos los costes indirectos.
También se lo conoce como el coste real del trabajo realizado. Véase también
gestión del valor ganado y técnica del valor ganado. También conocido como: Costo
Real.
Coste Real del Trabajo Realizado / Actual Cost of Work Performed (ACWP). Véase
coste real. También conocido como: Costo Real del Trabajo Realizado.
Creación de conexiones / Networking [Técnica]. Desarrollar relaciones con personas
que pueden ayudar a lograr objetivos y cumplir con responsabilidades. También
conocido como: Trabajo en Red.
Crear EDT (Estructura de Desglose del Trabajo) / Create WBS (Work Breakdown
Structure) [Proceso]. El proceso de subdividir los principales productos entregables
del proyecto y el trabajo del proyecto en componentes más pequeños y más fáciles
de manejar. También conocido como: Crear EDT (Estructura de Desagregación del
Trabajo); Crear EDT (Estructura de Descomposición del Trabajo); Crear EDT
(Estructura de la División del Trabajo); Crear EDT (Estructura Detallada del
Trabajo); Crear Estructura del Trabajo.
Criterios / Criteria. Normas, reglas o pruebas sobre las que se puede basar una opinión o
decisión, o por medio de la cual se puede evaluar un producto, servicio, resultado o
proceso.
Criterios de Aceptación / Acceptance Criteria. Aquellos criterios, incluidos los
requisitos de rendimiento y condiciones esenciales, que deben cumplirse antes de
que se acepten los productos entregables del proyecto.
Cronograma / Schedule. Véase cronograma del proyecto y véase también modelo del
cronograma.
Cronograma de hitos / Milestone Schedule [Herramienta]. Un cronograma resumido que
identifica los principales hitos del cronograma. Véase también cronograma maestro.
Cronograma del Proyecto / Project Schedule [Salida/Entrada]. Las fechas planificadas
para realizar las actividades del cronograma y las fechas planificadas para cumplir
los hitos del cronograma.
Cronograma Limitado por los Recursos / Resource-Limited Schedule. Un cronograma
del proyecto cuyas actividades planificadas, fechas de inicio planificadas y fechas de
finalización planificadas reflejan la disponibilidad prevista de los recursos. Un
cronograma limitado por los recursos no tiene fechas de inicio o finalización
tempranas ni tardías. La holgura total del cronograma limitado por los recursos
queda determinada al calcular la diferencia entre la fecha tardía de finalización del
método del camino crítico* y la fecha de finalización planificada limitada por los
recursos. A veces denominado cronograma restringido por los recursos. Véase
también nivelación de recursos.

209
Cronograma Maestro / Master Schedule [Herramienta]. Un cronograma del proyecto
resumido que identifica los principales productos entregables y componentes de la
estructura de desglose del trabajo y los hitos del cronograma clave. Véase también
cronograma de hitos.
Cronograma Planificado / Target Schedule. Un cronograma adoptado a los fines
comparativos durante el análisis de la red del cronograma, que puede ser diferente
del cronograma de referencia. Véase también referencia. También conocido como:
Cronograma Meta.
Cronograma Restringido por los Recursos / Resource-Constrained Schedule. Véase
cronograma limitado por los recursos.
Cuenta de Control / Control Account (CA) [Herramienta]. Un punto de control de
gestión donde se produce la integración entre el alcance, el presupuesto, el coste real
y el cronograma, y donde se mide el rendimiento. Las cuentas de control se colocan
en puntos de gestión seleccionados (componentes específicos en niveles
seleccionados) de la estructura de desglose del trabajo. Cada cuenta de control
puede incluir uno o más paquetes de trabajo, pero cada paquete de trabajo sólo
puede estar asociado con una cuenta de control. Cada cuenta de control está
asociada a un componente único y específico de la organización en la estructura de
desglose de la organización. Antes se llamaba Cuenta de Costes. Véase también
paquete de trabajo.
Curva S / S-Curve. Representación gráfica de los costes acumulativos, las horas de
mano de obra, el porcentaje de trabajo y otras cantidades, trazados en relación con el
tiempo. El nombre proviene de la forma en S de la curva (más uniforme al principio
y al final, más pronunciada en el medio) producida en un proyecto que comienza
despacio, se acelera y disminuye al final. Término que también se utiliza para la
distribución acumulada de probabilidad, que consiste en el resultado de una
simulación, una herramienta de análisis cuantitativo de riesgos.
Defecto / Defect. Una imperfección o deficiencia en un componente de un proyecto, que
hace que dicho componente no cumpla con sus requisitos o especificaciones y deba
ser reparado o reemplazado.
Definición de las Actividades / Activity Definition [Proceso]. El proceso de identificar
las actividades del cronograma específicas que deben realizarse para producir los
diversos productos entregables del proyecto.
Definición del Alcance / Scope Definition [Proceso]. El proceso de desarrollar un
enunciado del alcance del proyecto detallada como base para futuras decisiones del
proyecto.
Dependencia / Dependency. Véase relación lógica.
Desarrollo del Project Charter / Develop Project Charter [Proceso]. El proceso de
desarrollar el Project Charter que autoriza formalmente un proyecto. También
conocido como: Desarrollar el Acta de Autorización del Proyecto; Desarrollar el
Acta de Proyecto; o Desarrollar la Ficha del Proyecto.
Desarrollar el Enunciado del Alcance del Proyecto Preliminar / Develop Project Scope
Statement (Preliminary) [Proceso]. El proceso de desarrollar un enunciado del
alcance del proyecto, de carácter preliminar, que ofrezca una descripción del alcance
de alto nivel. También conocido como: Desarrollar la Definición del Alcance del
Proyecto (Preliminar) o Desarrollar la Descripción del Alcance del Proyecto.

210
Desarrollar el Equipo del Proyecto / Develop Project Team [Proceso]. El proceso de
mejorar las competencias y la interacción de los miembros del equipo para lograr un
mejor rendimiento del proyecto.
Desarrollar el Plan de Gestión del Proyecto / Develop Project Management Plan
[Proceso]. El proceso de documentar las medidas necesarias para definir, preparar,
integrar y coordinar todos los planes subsidiarios en un plan de gestión del proyecto.
También conocido como: Desarrollar el Plan de Administración de Proyectos;
Desarrollar el Plan de Administración del Proyecto; Desarrollar el Plan de Dirección
de Proyectos; Desarrollar el Plan de Gerenciamiento de Proyectos; o Desarrollar el
Plan Gerencial del Proyecto.
Desarrollo del Cronograma / Schedule Development [Proceso]. El proceso de analizar
las secuencias de las actividades del cronograma, la duración de las actividades del
cronograma, las necesidades de recursos y las restricciones del cronograma para
crear el cronograma del proyecto.
Descomponer / Decompose. Véase descomposición.
Descomposición / Decomposition [Técnica]. Una técnica de planificación que subdivide
el alcance del proyecto y los productos entregables del proyecto en componentes
más pequeños y más fáciles de manejar, hasta que el trabajo del proyecto asociado a
lograr el alcance del proyecto y a conseguir los productos entregables se defina con
detalle suficiente para poder respaldar la ejecución, el seguimiento y el control del
trabajo.
Descripción de la Actividad / Activity Description (AD). Una frase breve o etiqueta
para cada actividad del cronograma utilizada junto con un identificador de la
actividad con el fin de diferenciar esa actividad del cronograma del proyecto de
otras actividades del cronograma. Normalmente, la descripción de la actividad
describe el alcance del trabajo de la actividad del cronograma.
Descripción del Alcance del Producto / Product Scope Description. La descripción
narrativa documentada del alcance del producto.
Descripción del Cargo / Position Description [Herramienta]. Una explicación de los
roles y responsabilidades de un miembro del equipo del proyecto.
Diagrama de Barras / Bar Chart [Herramienta]. Representación gráfica de la
información relacionada con el cronograma. En un diagrama de barras típico, las
actividades del cronograma o componentes de la estructura de desglose del trabajo
se enumeran de forma descendente en el lado izquierdo del diagrama, las fechas
aparecen a lo largo de la parte superior, y la duración de las actividades se muestran
como barras horizontales ordenadas por fecha. También se conoce como diagrama
de Gantt.
Diagrama de Control / Control Chart [Herramienta]. Una representación gráfica de
datos del proceso a lo largo del tiempo y comparados con límites de control
establecidos, que cuentan con una línea central que ayuda a detectar una tendencia
de valores trazados con respecto a cualquiera de los límites de control. También
conocido como: Gráfico de Control.
Diagrama de Gantt / Gantt Chart. Véase diagrama de barras.
Diagrama de Influencias / Influence Diagram [Herramienta]. 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.

211
Diagrama de Pareto / Pareto Chart [Herramienta]. Un histograma, ordenado por la
frecuencia de ocurrencia, que muestra cuántos resultados fueron generados por cada
causa identificada.
Diagrama de Red del Cronograma del Proyecto / Project Schedule Network Diagram
[Salida/Entrada]. Toda representación esquemática de las relaciones lógicas que
existen entre las actividades del cronograma del proyecto. Siempre se traza de
izquierda a derecha para reflejar la cronología de trabajo del proyecto.
Diagrama de Red del Cronograma según Escala de Tiempo / Time-Scaled Schedule
Network Diagram [Herramienta]. Todo diagrama de red del cronograma del
proyecto diseñado de forma tal que la posición y la longitud de la actividad del
cronograma representa su duración. Esencialmente, es un diagrama de barras que
incluye la lógica de la red del cronograma.
Diagrama Lógico / Logic Diagram. Véase diagrama de red de cronograma del proyecto.
Diagramas de Flujo / Flowcharting [Técnica]. La representación en formato de
diagrama de los datos iniciales, medidas de un proceso y resultados de uno o más
procesos dentro de un sistema.
Diccionario de la Estructura de Desglose del Trabajo / Work Breakdown Structure
[Salida/Entrada]. Un documento que describe cada componente en la estructura de
desglose del trabajo (EDT). Para cada componente de la EDT, el diccionario de la
EDT incluye una breve definición del alcance o enunciado del trabajo, productos
entregables definidos, una lista de actividades asociadas y una lista de hitos. Otra
información puede incluir: la organización responsable, las fechas de inicio y
finalización, los recursos requeridos, una estimación del coste, el número de cargo,
la información del contrato, los requisitos de calidad y las referencias técnicas para
facilitar el rendimiento del trabajo. También conocido como: Diccionario de
Estructura de Descomposición del Trabajo; Diccionario de la Estructura de
Desagregación del Trabajo; Diccionario de la Estructura de la División del Trabajo;
Diccionario de la Estructura Detallada de Trabajo; Diccionario de la Estructura
Detallada del Trabajo; o Diccionario del Desglose de la Estructura del Trabajo.
Dirección de Programas / Program Management. La dirección coordinada centralizada
de un programa para lograr los objetivos y beneficios estratégicos del programa.
También conocido como: Administración de Programas; Gerencia de Programas;
Gerenciamiento de Programas; o Gestión de Programas.
Dirección de Proyectos / Project Management (PM). La aplicación de conocimientos,
habilidades, herramientas y técnicas a actividades del proyecto* para cumplir con
los requisitos del proyecto. También conocido como: Administración de Proyectos;
Gerencia de Proyectos; Gerenciamiento de Proyectos; o Gestión de Proyectos.
Director del Proyecto / Project Manager (PM). La persona nombrada por la
organización ejecutante para lograr los objetivos del proyecto*. También conocido
como: Administrador del Proyecto; Gerente de Proyectos; o Gerente del Proyecto.
Directorio del Equipo del Proyecto / Project Team Directory. Una lista documentada de
los miembros del equipo del proyecto, sus roles en el proyecto e información de
comunicación.
Dirigir y Gestionar la Ejecución del Proyecto / Direct and Manage Proyect Execution
[Proceso]. El proceso de ejecutar el trabajo definido en el plan de gestión del
proyecto para cumplir con los requisitos del proyecto definidos en el enunciado del
alcance del proyecto. También conocido como: Dirigir y Administrar la Ejecución
del Proyecto o Dirigir y Gerenciar la Ejecución del Proyecto.

212
Disciplina / Discipline. Un campo de trabajo que requiere conocimientos específicos y
tiene una serie de normas que rigen la conducta de trabajo (por ej., ingeniería
mecánica, programación de ordenadores, estimación de costes, etc.).
Disparadores / Triggers. Indicadores de qué ha ocurrido o está por ocurrir un riesgo. Los
disparadores pueden descubrirse en el proceso de identificación de riesgos y pueden
observarse en el proceso de seguimiento y control de riesgos. A veces se los llama
síntomas de riesgo o señales de advertencia.
Distribución de la Información / Information Distribution [Proceso]. El proceso de
poner la información necesaria a disposición de los interesados en el proyecto
cuando corresponda.
Divergencia de Camino / Path Divergence. Extensión o generación de caminos de red
de cronogramas paralelos de un mismo nodo en un diagrama de red de cronograma
del proyecto. La divergencia de caminos se caracteriza por una actividad del
cronograma con más de una actividad sucesora. También conocido como:
Divergencia de Rutas.
Documento / Document. Un medio y la información registrada en éste, que
generalmente es de carácter permanente y puede ser leído por una persona o una
máquina. Como ejemplos se pueden mencionar planes de dirección de proyectos,
especificaciones, procedimientos, estudios y manuales.
Documentos de la Adquisición / Procurement Documents [Salida/Entrada]. Los
Documentos que se usan en actividades de oferta y propuesta, que incluyen una
Invitación a Licitación del comprador, Invitación a Negociar, Solicitud de
Información, Solicitud de Presupuesto, Solicitud de Propuesta y respuestas del
proveedor. También conocido como: Documentos de las Adquisiciones.
Duración / Duration (DU or DUR). El total de períodos de trabajo (sin incluir
vacaciones u otros períodos no laborales) requeridos para 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 a tiempo transcurrido. Compárese con esfuerzo. Véase también
duración original, duración restante y duración real.
Duración de la Actividad / Activity Duration. El tiempo en unidades calendario entre el
inicio y la finalización de una actividad del cronograma. Véase también duración
real, duración original y duración restante.
Duración Original / Original Duration (OD). La duración de la actividad originalmente
asignada a una actividad del cronograma y no actualizada a medida que se informa
el avance sobre la actividad. Habitualmente se utiliza para realizar comparaciones
con la duración real y la duración restante al informar el avance del cronograma.
Duración Real / Actual Duration. El tiempo en unidades calendario entre la fecha de
inicio real de la actividad del cronograma y la fecha de los datos del cronograma del
proyecto si la actividad del cronograma se está desarrollando, o la fecha de
finalización real si ya se ha terminado la actividad del cronograma.
Duración Restante / Remaining Duration (RD). El tiempo en unidades calendario entre
la fecha de los datos del cronograma del proyecto y la fecha de finalización de una
actividad del cronograma que tiene una fecha de inicio real. Esto representa el
tiempo que se necesita para terminar una actividad del cronograma que tiene trabajo
en curso.
Ejecución / Executing. Véase ejecutar.

213
Ejecución Rápida / Fast Tracking [Técnica]. Una técnica específica de compresión del
cronograma de un proyecto que cambia la lógica de la red para solapar fases que
normalmente se realizarían en forma secuencial, tales como la fase de diseño y la
fase de construcción, o para llevar a cabo actividades del cronograma en forma
paralela. Véase compresión del cronograma y también intensificación. También
conocido como: Ejecucion Acelerada; Solapamiento; Superposición de actividades;
o Traslape de Actividades.
Ejecutar / Execute. Dirigir, gestionar, realizar y llevar a cabo el trabajo del proyecto,
proporcionar los productos entregables y brindar información sobre el rendimiento
del trabajo.
Elaboración Gradual / Progressive Elaboration [Técnica]. 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. También
conocido como: Elaboración Progresiva.
Elemento del Trabajo / Work Item. Este término ya no se utiliza. Véase actividad y
actividad del cronograma.
Empresa / Enterprise. Una compañía, negocio, firma, sociedad de personas, corporación
o agencia del gobierno.
Entrada / Input [Entrada del Proceso]. Cualquier elemento, interno o externo, del
proyecto que sea requerido por un proceso antes de que dicho proceso continúe.
Puede ser un resultado de un proceso predecesor.
Enunciado del Alcance del Proyecto / Project Scope Statement [Salida/Entrada]. La
descripción narrativa del alcance del proyecto, incluidos los principales productos
entregables, objetivos del proyecto, hipótesis del proyecto, restricciones del
proyecto y una descripción del trabajo, que brinda una base documentada que
permite tomar decisiones futuras sobre el proyecto, y confirmar o desarrollar un
entendimiento común del alcance del proyecto entre los interesados. La definición
del alcance del proyecto: aquello que se debe hacer para llevar a cabo el trabajo.
También conocido como: Definición del Alcance del Proyecto; Descripción del
Alcance del Proyecto; o Enunciado de Alcance del Proyecto.
Enunciado del Trabajo / Statement of Work (SOW). Una descripción narrativa de los
productos, servicios o resultados que deben suministrarse. También conocido como:
Definición del Trabajo o Descripción del Trabajo.
Enunciado del Trabajo del Contrato / Contract Statement of Work (SOW)
[Salida/Entrada]. Una descripción narrativa de los productos, servicios o resultados
que deben suministrarse en virtud de un contrato. También conocido como:
Descripción del Trabajo del Contrato.
Equipo de Dirección del Proyecto / Project Management Team. Los miembros del
equipo del proyecto que participan directamente en las actividades de dirección del
mismo. En algunos proyectos más pequeños, el equipo de dirección del proyecto
puede incluir prácticamente a todos los miembros del equipo del proyecto. También
conocido como: Equipo de Administración de Proyectos; Equipo de Gerencia de
Proyectos; Equipo de Gerenciamiento de Proyectos; o Equipo de Gestión de
Proyecto.

214
Equipo del Proyecto / Project Team. Todos los miembros del equipo del proyecto,
incluidos el equipo de dirección del proyecto, el director del proyecto y, para
algunos proyectos, el patrocinador del proyecto.
Equipo Virtual / Virtual Team. Un grupo de personas con un objetivo en común, que
cumple con sus respectivos roles empleando muy poco o nada de tiempo en
reuniones cara a cara. Por lo general, se utilizan varias tecnologías para facilitar la
comunicación entre los miembros del equipo. Los equipos virtuales pueden estar
compuestos por personas que están separadas por grandes distancias.

Esfuerzo / Effort. La cantidad de unidades laborales necesarias para terminar una

actividad del cronograma o un componente de la estructura de desglose del trabajo.
Generalmente se expresa como horas, días o semanas de trabajo del personal.
Compárese con duración.
Esfuerzo Discreto / Discrete Effort. Esfuerzo de trabajo que se identifica directamente
con la consecución de componentes y productos entregables específicos de la
estructura de desglose del trabajo, y que puede ser planificado y medido en forma
directa. Compárese con esfuerzo prorrateado. También conocido como: Esfuerzo
Específico.
Esfuerzo Prorrateado / Apportioned Effort (AE). Esfuerzo aplicado al trabajo de un
proyecto que no es fácilmente divisible en esfuerzos discretos para dicho trabajo,
pero que se relaciona en proporción directa con esfuerzos de trabajo discretos
medibles. Compárese con esfuerzo discreto.
Especificaciones / Specification. Un documento que especifica, 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 y, a
menudo, los procedimientos para determinar si se han cumplido con estas
disposiciones. Algunos ejemplos son: especificaciones de requisitos,
especificaciones de diseño, especificaciones del producto y especificaciones de
prueba.
Establecimiento de la Secuencia de las Actividades / Activity Sequencing [Proceso]. El
proceso de identificar y documentar dependencias entre actividades del cronograma.
También conocido como: Secuenciación de Actividades.
Estimación / Estimate [Salida/Entrada]. Una evaluación cuantitativa del monto o
resultado probable. Habitualmente se aplica a los costes, recursos, esfuerzo y
duraciones de los proyectos y normalmente está precedido por un calificador (por
ej., preliminar, conceptual, de factibilidad, de orden de magnitud, definitiva).
Siempre debería incluir alguna indicación de exactitud (por ej., ±x por ciento).
Estimación a la Conclusión / Estimate at Completion (EAC) [Salida/Entrada]. El coste
total previsto de una actividad del cronograma, de un componente de la estructura de
desglose del trabajo o del proyecto, cuando se complete el alcance definido del
trabajo. El EAC es igual al coste real (AC) más la estimación hasta la conclusión
(ETC) para todo el trabajo restante. EAC = AC más ETC. El EAC puede ser
calculado sobre la base del rendimiento hasta la fecha o estimado por el equipo del
proyecto sobre la base de otros factores, y en este caso se denomina última
estimación revisada. Véase también técnica del valor ganado y estimación hasta la
conclusión. También conocido como: Estimación a la Terminación.
Estimación Ascendente / Bottom-up Estimating [Técnica]. Un método de estimación de
un componente del trabajo. El trabajo se descompone más detalladamente. Se
prepara una estimación de lo que se necesita para cumplir con los requisitos de cada
215
 una de las partes del trabajo inferiores y más detalladas, y estas estimaciones se
suman luego a la cantidad total del componente del trabajo. La exactitud de la
estimación ascendente se basa en el tamaño y la complejidad del trabajo identificado
en los niveles inferiores. Por lo general, los trabajos con alcances más pequeños
aumentan la exactitud de las estimaciones.
Estimación de Costes / Cost Estimating [Proceso]. El proceso de desarrollar una
aproximación de los costes de los recursos necesarios para terminar las actividades
del proyecto*. También conocido como: Estimación de Costos.
Estimación de Costes / Should-Cost Estimates. Una estimación del coste de un producto
o servicio utilizado para proporcionar una evaluación de lo razonable que es el coste
propuesto de un posible proveedor. También conocido como: Estimación Base de
Costos; Estimación de Costos; o Estimación de lo que Debería Costar.
Estimación de la Duración de las Actividades / Activity Duration Estimating [Proceso].
El proceso de estimar el número de períodos laborables que se requerirán para
completar individualmente las actividades del cronograma.
Estimación de Recursos de las Actividades / Activity Resource Estimating [Proceso]. El
proceso de estimar los tipos y cantidades de recursos necesarios para realizar cada
actividad del cronograma.
Estimación hasta la Conclusión / Estimate to Complete (ETC) [Salida/Entrada]. El coste
previsto necesario para terminar todo el trabajo restante para una actividad del
cronograma, un componente de la estructura de desglose del trabajo o el proyecto.
Véase también técnica del valor ganado y estimación a la conclusión. También
conocido como: Estimación para Terminar.
Estimación Paramétrica / Parametric Estimating [Técnica]. Una técnica de estimación
que utiliza una relación estadística entre los datos históricos y otras variables (por
ej., pies cuadrados en la construcción; líneas de código en desarrollo de software)
para calcular una estimación de parámetros de una actividad tales como alcance,
coste, presupuesto y duración. Esta técnica puede dar resultados sumamente exactos,
de acuerdo con la complejidad y la información subyacente incorporada al modelo.
Un ejemplo del parámetro de costes se obtiene multiplicando la cantidad planificada
de trabajo que se deba realizar por el coste histórico por unidad, a fin de obtener el
coste estimado.
Estimación por Analogía / Analogous Estimating [Técnica]. Una técnica de estimación
que utiliza los valores de parámetros como el alcance, el coste, el presupuesto y la
duración o medidas de escala tales como el tamaño, el peso y la complejidad de una
actividad similar anterior como base para estimar el mismo parámetro o medida para
una actividad futura. Se utiliza frecuentemente para estimar un parámetro cuando la
cantidad de información detallada sobre el proyecto es limitada (por ejemplo, en
fases tempranas). La estimación por analogía es una clase de juicio de expertos. Las
estimaciones análogas son más fiables cuando las actividades previas son similares
de hecho y no sólo en apariencia, y los miembros del equipo del proyecto que
preparan las estimaciones tienen la experiencia necesaria. También conocido como:
Estimación Análoga.
Estimación por Tres Valores / Three-Point Estimate [Técnica]. Una técnica analítica que
utiliza tres estimaciones de coste o duración en las que se muestra un escenario
optimista, uno que es el más probable y uno pesimista. Esta técnica se aplica para
aumentar la precisión de las estimaciones de coste o duración, cuando el
componente de actividad o coste subyacente es incierto. También conocido como:
Estimación de Tres Puntos.
216
Estructura de Desglose de la Organización / Organizational Breakdown Structure (OBS)
[Herramienta]. Una descripción jerárquica de la organización del proyecto,
dispuesta de manera tal que se relacionen los paquetes de trabajo con las unidades
ejecutantes de la organización. También conocido como: Estructura de
Desagregación de la Organización; Estructura de Descomposición de la
Organización; Estructura de la División de la Organización; Estructura de la
Organización; o Estructura Detallada de la Organización.
Estructura de Desglose de Recursos / Resource Breakdown Structure (RBS). Una
estructura jerárquica de recursos por categoría de recurso y tipo de recurso utilizada
en la nivelación de recursos de los cronogramas y para desarrollar cronogramas
limitados por los recursos, y que puede usarse para identificar y analizar las
asignaciones de recursos humanos a los proyectos. También conocido como:
Desglose de la Estructura de Recursos; Estructura de Desagregación de Recursos;
Estructura de Descomposición de Recursos; Estructura de la División de Recursos;
o Estructura Detallada de Recursos.
Estructura de Desglose del Riesgo / Risk Breakdown Structure (RBS) [Herramienta].
Una descripción jerárquica de los riesgos del proyecto*, identificados y organizados
por categoría de riesgo y subcategoría, que identifica las distintas áreas y causas de
posibles riesgos. La estructura de desglose del riesgo a menudo suele adaptarse para
tipos de proyectos específicos. También conocido como: Desglose de la Estructura
de Riesgos; Estructura de Desagregación de Riesgos; Estructura de Descomposición
del Riesgo; Estructura de la División del Riesgo; Estructura Detallada de Riesgos; o
Estructura Detallada del Riesgo.
Estructura de Desglose del Trabajo (EDT) / Work Breakdown Structure (WBS)
[Salida/Entrada]. Una descomposición jerárquica con orientación hacia el producto
entregable relativa al trabajo que será ejecutado por el equipo del proyecto para
lograr los objetivos del proyecto y crear los productos entregables requeridos.
Organiza y define el alcance total del proyecto. Cada nivel descendente representa
una definición cada vez más detallada del trabajo del proyecto. La EDT se
descompone en paquetes de trabajo. La orientación hacia el producto entregable de
la jerarquía incluye los productos entregables internos y externos. Véase también
paquete de trabajo, cuenta de control, estructura de desglose del trabajo del contrato
y estructura de desglose del trabajo resumida del proyecto. También conocido como:
Desglose de la Estructura del Trabajo; Estructura de Desagregación del Trabajo
(EDT); Estructura de Descomposición del Trabajo (EDT); Estructura de la División
del Trabajo; Estructura Detallada de Trabajo (EDT); o Estructura Detallada del
Trabajo (EDT).
Estructura de Desglose del Trabajo del Contrato / Contract Work Breakdown Structure
(CWBS) [Salida/Entrada]. Una parte de la estructura de desglose del trabajo para el
proyecto desarrollado y mantenido por un proveedor que realiza una contratación
para proporcionar un subproyecto o un componente de un proyecto. También
conocido como: Desglose de la Estructura del Trabajo del Contrato; Estructura de
Desagregación del Trabajo del Contrato; Estructura de Descomposición del Trabajo
del Contrato; Estructura de Desglose del Trabajo Contratado; Estructura de la
División del Trabajo del Contrato; Estructura Detallada del Trabajo del Contrato; o
Estructura Detallada del Trabajo Subcontratada.
Estructura de Desglose del Trabajo del Proyecto Resumida / Project Summary Work
Breakdown Structure (PSWBS) [Herramienta]. Una estructura de desglose del
trabajo para el proyecto que sólo se desarrolla hasta el nivel de detalle de

217
 subproyecto dentro de algunas ramas de la (EDT), y en la cual los detalles de dichos
subproyectos se proporcionan por medio de estructuras de desglose del trabajo del
contrato. También conocido como: Desglose de la Estructura del Trabajo del
Proyecto Resumida; Estructura de Desagregación del Trabajo del Proyecto
Resumida; Estructura de Descomposición del Trabajo del Proyecto Resumida;
Estructura de la División del Trabajo del Proyecto Resumida; Estructura Detallada
del Trabajo del Proyecto Resumida; o Resumen de la Estructura Detallada de
Trabajo del Proyecto.
Evento / Event. Algo que ocurre, un acontecimiento, un resultado.
Evitar el Riesgo / Risk Avoidance [Técnica]. Una técnica de planificación de la
respuesta a los riesgos* ante una amenaza que genera cambios en el plan de gestión
del proyecto con la intención de eliminar el riesgo o proteger los objetivos del
proyecto de su impacto. Por lo general, la evitar el riesgo implica relajar los
objetivos de plazos, costes, alcance o calidad. También conocido como: Eliminación
del Riesgo; Evadir el Riesgo; o Prevención del Riesgo.
Extremo Abierto de la Red / Network Open End. Una actividad del cronograma sin
ninguna actividad predecesora ni una actividad sucesora que crea una pausa no
prevista en el camino de red de un cronograma. Los extremos abiertos de la red
habitualmente son causados por relaciones lógicas ausentes.
Factores Ambientales de la Empresa / Enterprise Environmental
Factors[Salida/Entrada]. Todos y cualquiera de los factores ambientales externos y
los factores ambientales internos de la organización que rodean o tienen alguna
influencia sobre el éxito del proyecto. Estos factores corresponden a todas o
cualquiera de las empresas involucradas en el proyecto, e incluyen la cultura y la
estructura de la organización, la infraestructura, los recursos existentes, las bases de
datos comerciales, las condiciones del mercado y el software de dirección de
proyectos de la organización.
Fase / Phase. Véase fase del proyecto.
Fase del Proyecto / Project Phase. Un conjunto de actividades del proyecto*
relacionadas lógicamente, que generalmente culminan con la finalización de un
producto entregable principal. Las fases del proyecto (también denominadas
simplemente fases) suelen completarse en forma secuencial, pero pueden
superponerse en determinadas situaciones de proyectos. Las fases pueden
subdividirse en subfases y, a su vez, en componentes; esta jerarquía, si el proyecto o
las partes del proyecto se dividen en fases, está contenida en la estructura de
desglose del trabajo. Una fase del proyecto es un componente de un ciclo de vida del
proyecto. Una fase del proyecto no es un grupo de procesos de dirección de
proyectos*.
Fecha / Date. Un término que representa el día, el mes y el año de un calendario y, en
algunas ocasiones, la hora.
Fecha Actual / Time-Now Date. Véase fecha de los datos.
Fecha de Conclusión Objetivo / Target Completion Date (TC). Una fecha impuesta que
restringe o modifica de alguna otra forma el análisis de la red del cronograma.
También conocido como: Fecha de Conclusión Meta; Fecha de Cumplimiento
Objetivo; o Fecha de Finalización Objetivo.

Fecha de Finalización / Finish Date. Un punto en el tiempo asociado con la conclusión

de una actividad del cronograma. Habitualmente es cualificada con una de las

218
 siguientes opciones: real, planificada, estimada, programada, temprana, tardía, de
referencia, objetivo o actual.
Fecha de Finalización Actual / Current Finish Date. La estimación actual del punto en el
tiempo en que se completará una actividad del cronograma. Dicha estimación refleja
cualquier avance del trabajo que haya sido informado. Véase también fecha de
finalización planificada y fecha de finalización de referencia.
Fecha de Finalización de Línea Base / Baseline Finish Date. La fecha de finalización de
una actividad del cronograma en la línea base del cronograma aprobada. Véase
también fecha de finalización planificada. También conocido como: Fecha de
Finalización de la Línea Base.
Fecha de Finalización Objetivo / Target Finish Date (TF). La fecha en la que se
planifica (se tiene como objetivo) finalizar el trabajo de una actividad del
cronograma. También conocido como: Fecha de Finalización Meta.
Fecha de Finalización Planificada / Scheduled Finish Date (SF). El momento de
finalización planificada del trabajo de una actividad del cronograma. Normalmente,
la fecha de finalización planificada se encuentra dentro del rango de fechas
delimitado por la fecha de finalización temprana y la fecha de finalización tardía.
Puede reflejar una nivelación de recursos de recursos escasos. A veces se denomina
fecha de finalización programada.
Fecha de Finalización Programada / Planned Finish Date (PF). Véase fecha de
finalización planificada.
Fecha de Finalización Real / Actual Finish Date (AF). El momento en que realmente
finalizó el trabajo de una actividad del cronograma. (Nota: En algunas áreas de
aplicación, una actividad del cronograma se considera "finalizada" cuando el trabajo
se ha "concluido sustancialmente").
Fecha de Finalización Tardía / Late Finish Date (LF). En el método del camino crítico,
el punto en el tiempo más lejano posible en que una actividad del cronograma puede
concluir, sobre la base de la lógica de la red del cronograma, la fecha de conclusión
del proyecto y cualquier restricción asignada a las actividades del cronograma sin
violar ninguna restricción del cronograma ni retrasar la fecha de conclusión del
proyecto. Las fechas de finalización tardías se determinan durante el cálculo del
recorrido hacia atrás de la red del cronograma del proyecto.
Fecha de Finalización Temprana / Early Finish Date (EF). En el método del camino
crítico, el punto en el tiempo más temprano posible en el cual las porciones no
completadas de una actividad del cronograma (o del proyecto) pueden finalizar,
sobre la base de la lógica de la red del cronograma, la fecha de los datos y cualquier
restricción del cronograma. Las fechas de finalización tempranas pueden cambiar a
medida que el proyecto avanza y a medida que se realizan cambios en el plan de
gestión del proyecto.
Fecha de Inicio / Start Date. Un punto en el tiempo asociado con el inicio de una
actividad del cronograma, habitualmente calificada con una de las siguientes
opciones: real, planificada, estimada, programada, temprana, tardía, objetivo de
referencia o actual.
Fecha de Inicio Actual / Current Start Date. La estimación actual del punto en el tiempo
en que se comenzará una actividad del cronograma. Dicha estimación refleja
cualquier avance del trabajo que haya sido informado. Véase también fecha de
inicio planificada y fecha de inicio de referencia.

219
Fecha de Inicio de Línea Base / Baseline Start Date. La fecha de inicio de una actividad
del cronograma en la línea base del cronograma aprobada. Véase también fecha de
inicio planificada. También conocido como: Fecha de Inicio de la Línea Base.
Fecha de Inicio Objetivo / Target Start Date (TS). La fecha en la que se planea (se tiene
como objetivo) comenzar el trabajo de una actividad del cronograma. También
conocido como: Fecha de Inicio Meta.
Fecha de Inicio Planificada / Scheduled Start Date (SS). El momento de inicio
planificado del trabajo de una actividad del cronograma. Normalmente, la fecha de
inicio planificada se encuentra dentro del rango de fechas delimitado por la fecha de
inicio temprana y la fecha de inicio tardía. Puede reflejar una nivelación de recursos
de recursos escasos. A veces se denomina fecha de inicio programada.
Fecha de Inicio Programada / Planned Start Date (PS). Véase fecha de inicio
planificada.
Fecha de Inicio Real / Actual Start Date (AS). El momento en que realmente se inició el
trabajo de una actividad del cronograma.
Fecha de Inicio Tardía / Late Start Date (LS). En el método del camino crítico, el punto
en el tiempo más lejano posible en que una actividad del cronograma puede
comenzar, sobre la base de la lógica de la red del cronograma, la fecha de
conclusión del proyecto, y cualquier restricción asignada a las actividades del
cronograma sin violar una restricción del cronograma ni retrasar la fecha de
conclusión del proyecto. Las fechas de inicio tardías se determinan durante el
cálculo del recorrido hacia atrás de la red del cronograma del proyecto.
Fecha de Inicio Temprana / Early Start Date (ES). En el método del camino crítico, el
punto en el tiempo más temprano posible en el cual las porciones no completadas de
una actividad del cronograma (o del proyecto) pueden comenzar, sobre la base de la
lógica de la red del cronograma, la fecha de los datos y cualquier restricción del
cronograma. Las fechas de inicio tempranas pueden cambiar a medida que el
proyecto avanza y a medida que se realizan cambios en el plan de gestión del
proyecto.
Fecha de los Datos / Data Date (DD). La fecha hasta la cual el sistema de generación de
informes del proyecto refleja la situación y los logros reales. En algunos sistemas de
generación de informes, la información de la situación a la fecha de los datos se
incluye en el pasado, y en otros la información de la situación se incluye a futuro.
También se denomina a la fecha de y fecha actual.
Fecha Impuesta / Imposed Date. Una fecha fija impuesta sobre una actividad del
cronograma o hito del cronograma, habitualmente expresada como una fecha que
exige “comenzar después del” y “finalizar antes del”.
Fiabilidad / Reliability. La probabilidad de que un producto cumpla con las funciones
para las cuales fue creado, en condiciones específicas, por un período de tiempo
determinado. También conocido como: Confiabilidad.
Final a Final / Finish-to-Finish (FF). La relación lógica en virtud de la cual el trabajo de
la actividad sucesora no puede finalizar hasta que concluya el trabajo de la actividad
predecesora. Véase también relación lógica. También conocido como: Final – Final.
Final a Inicio / Finish-to-Start (FS). La relación lógica en virtud de la cual el inicio del
trabajo de la actividad sucesora depende de la conclusión del trabajo de la actividad
predecesora. Véase también relación lógica. También conocido como: Terminar
para Iniciar o Final – Inicio.

220
Flecha / Arrow. La presentación gráfica de una actividad del cronograma en el método
de diagramación con flechas o de una relación lógica entre las actividades del
cronograma en el método de diagramación por precedencia.
Fondos / Funds. Reservas de dinero o recursos pecuniarios que se encuentran
disponibles en forma inmediata.
Fundamentos de la Dirección de Proyectos (PMBOK®) / Project Management Body of
Knowledge (PMBOK®). Expresión inclusiva que describe la suma de
conocimientos de la profesión de dirección de proyectos. Al igual que en otras
profesiones, como la abogacía, la medicina y las ciencias económicas, los
fundamentos residen en los practicantes y académicos que los aplican y desarrollan.
El conjunto de los fundamentos de la dirección de proyectos incluye prácticas
tradicionales comprobadas y ampliamente utilizadas así como prácticas innovadoras
emergentes para la profesión. Los fundamentos incluyen tanto material publicado
como no publicado. El PMBOK evoluciona de forma constante. También conocido
como: Conjunto de Conocimientos de la Dirección de Proyectos; Cuerpo de
Conocimientos de la Administración de Proyectos; Fundamentos de la Gerencia de
Proyectos; Fundamentos de la Gestión de Proyectos; o Fundamentos del
Gerenciamiento de Proyectos.
Gerente Funcional / Functional Manager. Alguien con autoridad de dirección sobre una
unidad de la organización dentro de una organización funcional. El gerente de
cualquier grupo que efectivamente realiza un producto o presta un servicio. A veces
se le denomina gerente de línea.
Gestión de la Calidad del Proyecto / Project Quality Management [Área de
Conocimiento]. Véase Apéndice G. También conocido como: Administración de la
Calidad del Proyecto; Gerencia de la Calidad del Proyecto; o Gerenciamiento de
Calidad del Proyecto.
Gestión de la Calidad Total / Total Quality Management (TQM) [Técnica]. Un enfoque
común para la implantación de un programa de mejora de la calidad dentro de una
organización. También conocido como: Administración de la Calidad Total;
Gerencia de la Calidad Total; o Gerenciamiento por Calidad Total.
Gestión de la Integración del Proyecto / Project Integration Management [Área de
Conocimiento]. Véase Apéndice G. También conocido como: Administración de la
Integración del Proyecto; Gerencia de la Integración del Proyecto; o Gerenciamiento
de la Integración del Proyecto.
Gestión de las Adquisiciones del Proyecto / Project Procurement Management [Área de
Conocimiento]. Véase Apéndice G. También conocido como: Administración de las
Adquisiciones del Proyecto; Gerencia de las Adquisiciones del Proyecto; o
Gerenciamiento de Adquisiciones del Proyecto.
Gestión de las Comunicaciones del Proyecto / Project Communications Management
[Área de Conocimiento]. Véase Apéndice G. También conocido como:
Administración de las Comunicaciones del Proyecto; Gerencia de las
Comunicaciones del Proyecto; o Gerenciamiento de las Comunicaciones del
Proyecto.
Gestión de los Costes del Proyecto / Project Cost Management [Área de Conocimiento].
Véase Apéndice G. También conocido como: Administración de los Costos del
Proyecto; Gerencia de los Costos del Proyecto; Gerenciamiento de los Costos del
Proyecto; o Gestión de los Costos del Proyecto.

221
Gestión de los Recursos Humanos del Proyecto / Project Human Resource Management
[Área de Conocimiento]. Véase Apéndice G. También conocido como:
Administración de los Recursos Humanos del Proyecto; Gerencia de los Recursos
Humanos del Proyecto; o Gerenciamiento de los Recursos Humanos del Proyecto.
Gestión de los Riesgos del Proyecto / Project Risk Management [Área de
Conocimiento]. Véase Apéndice G. También conocido como: Administración de los
Riesgos del Proyecto; Administración de Riesgos del Proyecto; Gerencia de los
Riesgos del Proyecto; o Gerenciamiento de Riesgos del Proyecto.
Gestión del Alcance del Proyecto / Project Scope Management [Área de Conocimiento].
Véase Apéndice G. También conocido como: Administración del Alcance del
Proyecto; Gerencia del Alcance del Proyecto; o Gerenciamiento del Alcance del
Proyecto.
Gestión del Portafolio / Portfolio Management [Técnica]. La gestión centralizada de uno
o más portafolios, que incluye la identificación, priorización, autorización, gestión y
control de proyectos, programas y otros trabajos relacionados, a fin de alcanzar
objetivos estratégicos de negocio específicos. También conocido como:
Administración del Portafolio; Gerencia del Portafolio; o Gerenciamiento del
Portafolio.
Gestión del Tiempo del Proyecto / Project Time Management [Área de Conocimiento].
Véase Apéndice G. También conocido como: Administración del Tiempo del
Proyecto; Gerencia del Tiempo del Proyecto; o Gerenciamiento del Tiempo del
Proyecto.
Gestión del Valor Ganado / Earned Value Management (EVM). Una metodología de
gestión para integrar alcance, cronograma y recursos, y para medir el rendimiento y
el avance del proyecto en forma objetiva. El rendimiento se mide determinando el
coste presupuestado del trabajo realizado (es decir, el valor ganado) y comparándolo
con el coste real del trabajo realizado (es decir, el coste real). El avance se mide
comparando el valor ganado con el valor planificado. También conocido como:
Administración del Valor del Trabajo Realizado; Administración del Valor Ganado;
Gerencia de Valor Ganado; o Gerenciamiento del Valor Ganado.
Gestionar a los Interesados / Manage Stakeholders [Proceso]. El proceso de gestionar
las comunicaciones para satisfacer los requisitos de los interesados en el proyecto y
resolver problemas con ellos. También conocido como: Administrar a los
Interesados; Dirigir a los Interesados; Dirigir a los Involucrados; Gerenciar a los
Interesados; o Gerenciar a los Involucrados.
Gestionar el Equipo del Proyecto / Manage Project Team [Proceso]. El proceso de hacer
un seguimiento del rendimiento de los miembros del equipo, proporcionar
comentarios, resolver problemas y coordinar cambios para mejorar el rendimiento
del proyecto. También conocido como: Administrar el Equipo de Proyecto; Dirigir
el Equipo del Proyecto; o Gerenciar el Equipo del Proyecto.
Grado / Grade. Categoría o escala que se utiliza para distinguir elementos que tienen el
mismo uso funcional (por ej., "martillo") pero que no comparten los mismos
requisitos de calidad (por ej., distintos martillos pueden tener resistencia a distintos
grados de fuerza).
Grupo de Procesos / Process Group. Véase Grupos de Procesos de Dirección de
Proyectos.
Grupo de Procesos de Dirección de Proyectos / Project Management Process Group. Un
modo lógico de agrupar los procesos de dirección de proyectos que se describe en la

222
 Guía del PMBOK®. Los grupos de procesos de dirección de proyectos incluyen
procesos de iniciación, procesos de planificación, procesos de ejecución, procesos
de seguimiento y control, y procesos de cierre. En conjunto, estos cinco grupos son
necesarios para cualquier proyecto, deben contar con dependencias internas claras, y
deben llevarse a cabo con la misma secuencia en cada proyecto, independientemente
del área de aplicación o detalles específicos del ciclo de vida del proyecto aplicado.
Los grupos de procesos de dirección de proyectos no son fases del proyecto.
También conocido como: Grupo de Procesos de Administración de Proyectos;
Grupo de Procesos de Gerencia de Proyectos; Grupo de Procesos de Gerenciamiento
de Proyectos; o Grupo de Procesos de Gestión de Proyectos.
Grupos de Procesos del Proyecto / Project Process Groups. Los cinco grupos de
procesos necesarios para cualquier proyecto que cuentan con dependencias claras, y
que deben llevarse a cabo con la misma secuencia en cada proyecto,
independientemente del área de aplicación o detalles específicos del ciclo de vida
del proyecto aplicado. Los grupos de procesos son: iniciación, planificación,
ejecución, supervisión y control, y cierre.
Habilidad / Skill. Capacidad para usar los conocimientos, una aptitud desarrollada o una
capacidad para ejecutar o realizar una actividad en forma eficiente y de inmediato.
Herramienta / Tool. Algo tangible, como una plantilla o un programa de software,
utilizado al realizar una actividad para producir un producto o resultado.
Histograma de Recursos / Resource Histogram. Un diagrama de barras que muestra la
cantidad de tiempo que un recurso está planificado 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.
Hito / Milestone. Un punto o evento significativo dentro del proyecto. Véase también
hito del cronograma.
Hito del Cronograma / Schedule Milestone. Un evento importante del cronograma del
proyecto, por ejemplo, un evento que impide que se lleve a cabo un trabajo en el
futuro o que marca la conclusión de un producto entregable principal. Un hito del
cronograma tiene duración cero. A veces se le denomina actividad hito. Véase
también hito.
Holgura / Float. También se denomina margen. Véase holgura total y también holgura
libre.
Holgura / Slack. Véase holgura total y holgura libre.
Holgura Libre / Free Float (FF). La cantidad de tiempo que una actividad del
cronograma puede demorarse sin demorar el inicio temprano de cualquier actividad
del cronograma inmediatamente posterior. Véase también holgura total.
Holgura Total / Total Float (TF). La cantidad total de tiempo que una actividad del
cronograma puede retrasarse respecto de su fecha de inicio temprana sin retrasar la
fecha de finalización del proyecto ni violar una restricción del cronograma. Se
calcula utilizando la técnica del método del camino crítico y determinando la
diferencia entre las fechas de finalización tempranas y las fechas de finalización
tardías. Véase también holgura libre.
Identificación de Riesgos / Risk Identification [Proceso]. El proceso de determinar qué
riesgos podrían afectar el proyecto y documentar sus características.
Identificador de la Actividad / Activity Identifier. Una breve y única identificación
numérica o de texto asignada a cada actividad del cronograma a fin de diferenciar
223
 esa actividad del proyecto de otras actividades. Generalmente, es único dentro de
cualquier diagrama de red del cronograma del proyecto.
Índice de Rendimiento del Coste / Cost Performance Index (CPI). Una medida de
eficiencia en función de los costes con respecto a un proyecto. Es la relación valor
ganado (EV) y costes reales (AC). CPI = EV dividido AC. Un valor igual o mayor
que uno indica una condición favorable, y un valor menor que uno indica una
condición desfavorable. También conocido como: Índice de Desempeño de Costos;
Índice de Rendimiento de Costo; Índice de Rendimiento del Costo; o Índice del
Desempeño de Costos.

Índice de Rendimiento del Cronograma / Schedule Performance Index (SPI). Una

medida de eficiencia del cronograma en un proyecto. Es la razón entre el valor
ganado (EV) y valor planificado (PV). SPI = EV dividido PV. Un SPI igual o mayor
que uno indica una condición favorable, y un valor menor que uno indica una
condición desfavorable. Véase también gestión del valor ganado. También conocido
como: Índice de Desempeño del Cronograma.
Influyentes / Influencer. Personas o grupos que no están directamente relacionados con
la adquisición o el uso del producto del proyecto, pero que, debido a su posición en
la organización del cliente*, pueden ejercer una influencia positiva o negativa sobre
el curso del proyecto. También conocido como: Influenciador o Influyente.
Información Histórica / Historical Information. Documentos y datos sobre proyectos
anteriores, que incluyen archivos de proyectos, registros, correspondencias,
contratos completados y proyectos cerrados.
Información sobre el Rendimiento del Trabajo / Work Performance Information
[Salida/Entrada]. Información y datos, sobre la situación de las actividades del
cronograma del proyecto, que se estén llevando a cabo para lograr el trabajo del
proyecto, recabados como parte de los procesos de dirigir y gestionar la ejecución
del proyecto*. La información incluye: situación de los productos entregables;
situación de implantación para solicitudes de cambio, acciones correctivas, acciones
preventivas y reparación de defectos; estimaciones hasta la conclusión
pronosticadas; porcentaje informado del trabajo físicamente terminado; valor de
medidas del rendimiento técnico alcanzado; fechas de inicio y finalización de las
actividades del cronograma. También conocido como: Información sobre el
Desempeño del Trabajo.
Informar el Rendimiento / Performance Reporting [Proceso]. El proceso de recolectar y
distribuir información sobre el rendimiento. Esto incluye informes de situación,
medición del avance y previsiones. También conocido como: Informar acerca del
Rendimiento; Informar el desempeño; Informes de Desempeño; o Reportar el
Rendimiento.
Informe por Excepción / Exception Report. Un documento que incluye únicamente las
principales variaciones del plan (en lugar de todas las variaciones). También
conocido como: Informe de Excepciones o Reporte por Excepción.
Informes de Rendimiento / Performance Reports [Salida/Entrada]. Documentos y
presentaciones que ofrecen información organizada y resumida sobre el rendimiento
del trabajo, parámetros y cálculos de la gestión del valor ganado, y análisis del
avance y situación del trabajo del proyecto. Los formatos comunes para los informes
de rendimiento incluyen diagramas de barras, curvas S, histogramas, tablas y el
diagrama de red del cronograma del proyecto que muestra la situación actual del

224
 cronograma. También conocido como: Informes de Desempeño o Reportes de
Rendimiento.
Ingeniería del Valor / Value Engineering (VE). Un enfoque creativo utilizado para
optimizar los costes del ciclo de vida del proyecto, ahorrar tiempo, aumentar las
ganancias, mejorar la calidad, ampliar la participación en el mercado, resolver
problemas, o utilizar recursos en forma más eficiente.
Iniciación del Proyecto / Project Initiation. Lanzar un proceso que puede dar por
resultado la autorización y definición del alcance de un nuevo proyecto.
Iniciador / Initiator. Una persona u organización que tiene tanto la capacidad como la
autoridad para iniciar un proyecto.
Inicio a Fin / Start-to-Finish (SF). La relación lógica en la cual la conclusión de la
actividad del cronograma sucesora depende de la iniciación de la actividad del
cronograma predecesora. Véase también relación lógica. También conocido como:
Iniciar para Terminar.
Inicio a Inicio / Start-to-Start (SS). La relación lógica en la cual el inicio del trabajo de
la actividad del cronograma sucesora depende del inicio del trabajo de la actividad
del cronograma predecesora. Véase también relación lógica.
Inspección / Inspection [Técnica]. Examen o medición para verificar si una actividad,
componente, producto, resultado o servicio cumple con requisitos específicos.
Integrado / Integrated. Componentes interrelacionados, interconectados, entrelazados o
entramados que se mezclan y unen como un todo funcional o unificado.
Integral / Integral. Esencial para la completitud; necesario; parte constituyente de un
todo; que forma una unidad con otro componente.
Intensificación / Crashing [Técnica]. Un tipo específico de técnica de compresión del
cronograma del proyecto realizada al tomar las medidas necesarias para disminuir la
duración del cronograma del proyecto total* después de analizar varias alternativas
para determinar cómo obtener la máxima compresión de la duración del cronograma
al menor coste adicional posible. Los enfoques típicos para la intensificación de un
cronograma incluyen reducir la duración de la actividad del cronograma y aumentar
la asignación de recursos para las actividades del cronograma. Véase compresión del
cronograma y véase también seguimiento rápido. También conocido como:
Compresión.
Interesado / Stakeholder. Personas y organizaciones como clientes, patrocinadores,
organización ejecutante y el público, involucrados activamente con 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
productos entregables. También conocido como: Interesados o Involucrados.
Interesado en el Proyecto / Project Stakeholder. Véase interesados. También conocido
como: Interesados en el Proyecto o Involucrado en el Proyecto.
Invitación a Licitación / Invitation for Bid (IFB). En general, este término es
equivalente a solicitud de propuesta. No obstante, en algunas áreas de aplicación, es
posible que tenga una acepción más concreta o más específica. También conocido
como: Invitación a Licitar; Invitación a Ofertar; o Llamado a Licitación.
Juicio de Expertos / Expert Judgement [Técnica]. Un juicio que se brinda sobre la base
de la experiencia en un área de aplicación, área de conocimiento, disciplina,
industria, etc. según resulte apropiado para la actividad que se está llevando a cabo.
Dicha experiencia puede ser proporcionada por cualquier grupo o persona con una

225
 educación, conocimiento, habilidad, experiencia o capacitación especializada, y
puede obtenerse de numerosas fuentes, incluyendo: otras unidades dentro de la
organización ejecutante; consultores; interesados, incluidos clientes; asociaciones
profesionales y técnicas; y grupos industriales.
Lecciones Aprendidas / Lessons Learned [Salida/Entrada]. Lo que se aprende en el
proceso de realización del proyecto. Las lecciones aprendidas pueden identificarse
en cualquier momento. También considerado un registro del proyecto, que se debe
incluir en la base de conocimientos de lecciones aprendidas.
Límites de Control / Control Limits. El área compuesta por tres desviaciones estándar a
cada lado de la línea central, o promedio, de una distribución de datos normal
trazada en un diagrama de control que refleja la variación prevista de los datos.
Véase también límites de las especificaciones.
Límites de las Especificaciones / Specification Limits. El área, a cada lado de la línea
central, o promedio, de datos trazados en un diagrama de control que cumple con los
requisitos del cliente para un producto o servicio. Esta área puede ser mayor o
menor que el área definida por los límites de control. Véase también límites de
control.
Línea Base / Baseline. El plan de fases de tiempo aprobado (para un proyecto, un
componente de la estructura de desglose del trabajo, un paquete de trabajo o una
actividad del cronograma), más o menos el alcance del proyecto, el coste, el
cronograma y los cambios técnicos. Por lo general, se refiere a la referencia actual,
pero también puede referirse a la referencia original o a alguna otra referencia.
Generalmente, se utiliza con un modificador (por ej., costes de referencia, referencia
del cronograma, referencia para la medición del rendimiento, referencia técnica).
Véase también línea base para la medición del rendimiento.
Línea Base de Coste / Cost Baseline. Véase referencia. También conocido como: Línea
Base de Costo o Línea Base de Costos.
Línea Base del Alcance / Scope Baseline. Véase referencia.
Línea Base para la Medición del Rendimiento / Performance Measurement Baseline. Un
plan aprobado para el trabajo del proyecto contra el que se compara la ejecución del
proyecto y se miden las desviaciones con el fin de un control de gestión. Por lo
general, la referencia para la medición del rendimiento incluye los parámetros de
alcance, cronograma y coste de un proyecto, pero también puede incluir parámetros
técnicos y de calidad. También conocido como: Línea Base para la Medición del
Desempeño.
Lista de Actividades / Activity List [Salida/Entrada]. Una tabla documentada de las
actividades del cronograma que muestra la descripción de la actividad, el
identificador de la actividad y una descripción suficientemente detallada del alcance
del trabajo para que los miembros del equipo del proyecto comprendan cuál es el
trabajo que deben realizar.
Lista de Control / Checklist [Salida/Entrada]. Elementos que se enumeran juntos para
facilitar su comparación o para asegurar que las medidas asociadas con ellos se
traten adecuadamente y no sean olvidadas. Se puede mencionar como ejemplo una
lista de elementos que debe ser inspeccionada y que se crea durante la planificación
de calidad y se aplica durante el control de calidad. También conocido como: Lista
de Chequeos.

226
Lista de Materiales / Bill of Materials (BOM). Una tabla formalmente documentada y
ordenada en forma jerárquica que incluye los conjuntos, subconjuntos y
componentes físicos necesarios para fabricar un producto.
Lógica / Logic. Véase lógica de la red.
Lógica de la Red / Network Logic. El conjunto de dependencias de actividades del
cronograma que conforma un diagrama de red de cronograma del proyecto.
Material / Materiel. El conjunto de objetos utilizados por una organización en una tarea,
tales como equipos, aparatos, herramientas, maquinaria, útiles, materiales y
suministros. También conocido como: Materiales y Equipamiento.
Matriz de Asignación de Responsabilidades / Responsibility Assignment Matrix (RAM)
[Herramienta]. Una estructura que relaciona la estructura de desglose de la
organización con la estructura de desglose del trabajo para ayudar a garantizar que
cada componente del alcance del proyecto se asigne a una persona responsable.
Matriz de Probabilidad e Impacto / Probability and Impact Matrix [Herramienta]. Una
manera común de determinar si un riesgo se considera bajo, moderado o alto
mediante la combinación de las dos dimensiones de un riesgo: su probabilidad de
ocurrencia y su impacto sobre los objetivos, en caso de ocurrir.
Medición del Rendimiento Técnico / Technical Performance Measurement [Técnica].
Una técnica de medición del rendimiento que compara los logros técnicos durante la
ejecución del proyecto con el cronograma del plan de gestión del proyecto de
resultados técnicos planificados. Puede utilizar parámetros técnicos clave del
producto producido por el proyecto como métrica de calidad. Los valores métricos
alcanzados son parte de la información sobre el rendimiento del trabajo. También
conocido como: Medición del Desempeño Técnico.
Método de Cadena Crítica / Critical Chain Method [Técnica]. Una técnica de análisis de
la red del cronograma* que permite modificar el cronograma del proyecto para
adaptarlo a los recursos limitados. El método de cadena crítica combina enfoques
deterministas y probabilistas para el análisis de la red del cronograma. También
conocido como: Método de la Ruta Crítica.
Método de Diagramación con Flechas / Arrow Diagramming Method (ADM) [Técnica].
Una técnica de diagramación de redes del cronograma en la cual las actividades del
cronograma están representadas con flechas. El extremo inferior de la flecha
representa el punto de inicio, y la punta de la flecha representa el punto de
finalización de la actividad del cronograma. (La longitud de la flecha no representa
la duración prevista de la actividad del cronograma). Las actividades del
cronograma se conectan en puntos llamados nodos (que generalmente se dibujan en
forma de pequeños círculos) para ilustrar la secuencia prevista para realizarlas.
Véase también método de diagramación por precedencia.
Método de Diagramación por Precedencia / Precedence Diagramming Method (PDM)
[Técnica]. La técnica de diagramación de redes del cronograma en la cual las
actividades del cronograma se representan con casilleros (o nodos). Las actividades
del cronograma se vinculan gráficamente mediante una o más relaciones lógicas
para mostrar la secuencia en que deben realizarse las actividades.
Método del Camino Crítico / Critical Path Method (CPM) [Técnica]. Una técnica de
análisis de la red del cronograma* que se usa para determinar el nivel de margen de
los cronogramas (el nivel de holgura) sobre varios caminos de red lógicos de la red
del cronograma del proyecto y para determinar la duración total mínima del
proyecto. Las fechas de inicio y finalización tempranas* se calculan mediante un

227
 recorrido hacia adelante, usando una fecha de inicio especificada. Las fechas de
inicio y finalización tardías* se calculan mediante un recorrido hacia atrás, a partir
de una fecha de finalización especificada, que generalmente es la fecha de
finalización temprana del proyecto determinada durante el cálculo del recorrido
hacia adelante. También se denomina Método de la Ruta Crítica.
Metodología / Methodology. Un sistema de prácticas, técnicas, procedimientos y
normas utilizado por quienes trabajan en una disciplina.
Miembros del Equipo / Team Members. Véase miembros del equipo del proyecto.
Miembros del Equipo del Proyecto / Project Team Members. Las personas que
dependen, ya sea directa o indirectamente, del director de proyectos, y que son
responsables de realizar el trabajo del proyecto como parte regular de sus
obligaciones asignadas.
Mitigar el riesgo / Risk Mitigation [Técnica]. Una técnica de planificación de la
respuesta a los riesgos* asociada con amenazas que pretende reducir la probabilidad
de ocurrencia o el impacto de un riesgo por debajo de un umbral aceptable. También
conocido como: Disminuir el Riesgo o Mitigación del Riesgo.
Modelo de Cronograma / Schedule Model [Herramienta]. Un modelo usado junto con
métodos manuales o software de gestión de proyectos para realizar un análisis de la
red del cronograma a fin de generar el cronograma del proyecto, para usarlo al
gestionar la ejecución de un proyecto. Véase también cronograma del proyecto.
Nivel de Esfuerzo / Level of Effort (LOE). Actividad de soporte (por ej., vínculo entre
el proveedor o el cliente, contabilidad de costes de proyectos, dirección de
proyectos, etc.) cuyo cumplimiento diferenciado no es fácil de medir. Generalmente
se caracteriza por un índice uniforme de rendimiento de trabajo a lo largo de un
período determinado por las actividades a las cuales se brinda soporte.
Nivelación / Leveling. Véase nivelación de recursos.
Nivelación de Recursos / Resource Leveling [Técnica]. Cualquier forma de análisis de
la red del cronograma en que las decisiones de planificación (fechas de inicio y de
finalización) se basan en aspectos relativos a las restricciones de los recursos (por
ej., disponibilidad de recursos limitados o cambios de difícil gestión en los niveles
de disponibilidad de recursos).
Nodo / Node. Uno de los puntos que definen la red de un cronograma; un punto de
intercepción unido a algunas o todas las demás líneas de la dependencia. Véase
también método de diagramación con flechas y método de diagramación por
precedencia.
Norma / Standard. Un documento establecido por consenso y aprobado por un cuerpo
reconocido que proporciona, para uso común y repetido, reglas, pautas o
características para actividades o sus resultados, orientado a lograr el óptimo grado
de orden en un contexto determinado. También conocido como: Estándar.
Objetivo / Objective. Una meta hacia la cual se debe dirigir el trabajo, una posición
estratégica que se quiere lograr o un fin que se desea alcanzar, un resultado a
obtener, un producto a producir o un servicio a prestar.
Oficina de Gestión de Programas / Program Management Office (PMO). La gestión
centralizada de un programa o programas en particular, de modo tal que los
beneficios corporativos se obtienen a través de los recursos, metodologías,
herramientas y técnicas compartidas y del enfoque relacionado en una dirección de
proyectos de alto nivel. Véase también oficina de gestión de proyectos. También
conocido como: Oficina de Administración de Programas; Oficina de Dirección de
228
 Programas; Oficina de Gerencia de Programas; Oficina de Gerenciamiento de
Programas.
Oficina de Gestión de Proyectos / Project Management Office (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 gestión de proyectos
pueden variar, desde realizar funciones de soporte para la dirección de proyectos
hasta ser realmente los responsables de la dirección de un proyecto. Véase también
oficina de gestión de programas. También conocido como: Oficina de
Administración de Proyectos; Oficina de Dirección de Proyectos; Oficina de
Gerencia de Proyectos; u Oficina del Gerenciamiento de Proyectos.
Operaciones / Operations. Una función de la organización que se ocupa de la ejecución
constante de actividades que generan el mismo producto o prestan un servicio
reiterado. Algunos ejemplos son: operaciones de producción, operaciones de
fabricación y operaciones de contabilidad.
Opinión del Cliente / Voice of the Customer. Una técnica de planificación utilizada para
brindar productos, servicios y resultados que reflejan fielmente los requisitos del
cliente al traducir aquellos requisitos del cliente en los requisitos técnicos adecuados
para cada fase de desarrollo de producto del proyecto. También conocido como:
Voz del Cliente.
Oportunidad / Opportunity. Una condición o situación favorable para el proyecto, un
conjunto de circunstancias positivas, un conjunto de eventos positivos, un riesgo que
tendrá un impacto positivo sobre los objetivos del proyecto, o una posibilidad de
realizar cambios positivos. Compárese con amenaza.
Organigrama / Organization Chart [Herramienta]. Un método para describir las
interrelaciones entre un grupo de personas que trabajan juntas para lograr un
objetivo común.
Organigrama del Proyecto / Project Organization Chart [Salida/Entrada]. Un documento
que representa gráficamente a los miembros del equipo del proyecto y sus
interrelaciones para un proyecto específico.
Organización / Organization. Un grupo de personas organizadas para algún fin o para
llevar a cabo algún tipo de trabajo dentro de una empresa.
Organización Ejecutante / Performing Organization. La empresa cuyo personal participa
más directamente en el trabajo del proyecto. También conocido como: Organización
Ejecutora.
Organización Funcional / Functional Organization. Una organización jerárquica en la
cual cada empleado tiene definido claramente un superior, y el personal está
agrupado por áreas de especialización dirigidas por una persona con experiencia en
esa área.
Organización Matricial / Matrix Organization. Una estructura de organización en la cual
el director del proyecto comparte con los gerentes funcionales la responsabilidad de
asignar prioridades y de dirigir el trabajo de las personas asignadas al proyecto.
Organización Orientada a Proyectos / Projectized Organization. Cualquier estructura
organizativa en la que el director del proyecto tiene plena autoridad para asignar
prioridades, asignar recursos y dirigir el trabajo de las personas asignadas al
proyecto. También conocido como: Organización Dirigida por Proyectos;
Organización por Proyectos; u Organización Proyectizada.

229
Paquete de Planificación / Planning Package. Un componente de la EDT por debajo de
la cuenta de control con contenido de trabajo conocido pero sin actividades del
cronograma detalladas. Véase también cuenta de control. También conocido como:
Paquete de Planeación.
Paquete de Trabajo / Work Package. Un producto entregable o componente del trabajo
del proyecto en el nivel más bajo de cada sector de la estructura de desglose del
trabajo. El paquete de trabajo incluye las actividades del cronograma y los hitos del
cronograma requeridos para completar el producto entregable del paquete de trabajo
o el componente del trabajo del proyecto. Véase también control de cuenta.
Patrocinador / Sponsor. La persona o el grupo que ofrece recursos financieros,
monetarios o en especie, para el proyecto. También conocido como: Patrocinante.
Patrocinador del Proyecto / Project Sponsor. Véase patrocinador. También conocido
como: Patrocinador de Proyecto.
Plan de Cuentas / Chart of Accounts [Herramienta]. Todo sistema de numeración que se
utilice para supervisar los costes del proyecto* por categoría (por ej., mano de obra,
suministros, materiales y equipos). El plan de cuentas del proyecto se basa
generalmente en el plan empresarial de cuentas de la organización ejecutante
principal. Compárese con código de cuentas. También conocido como: Catálogo de
Cuentas o Matriz de Códigos de Cuentas.
Plan de Gestión de Calidad / Quality Management Plan [Salida/Entrada]. El plan de
gestión de calidad describe cómo el equipo de dirección del proyecto implementará
la política de calidad de la organización ejecutante. El plan de gestión de calidad es
un componente o un plan subsidiario al plan de gestión del proyecto. El plan de
gestión de calidad puede ser formal o informal, muy detallado o ampliamente
esbozado, dependiendo de los requisitos del proyecto. También conocido como:
Plan de Administración de Calidad; Plan de Gerencia de Calidad; o Plan de
Gerenciamiento de Calidad.
Plan de Gestión de Costes / Cost Management Plan [Salida/Entrada]. El documento que
fija el formato y establece las actividades y los criterios necesarios para planificar,
estructurar y controlar los costes del proyecto. Dependiendo de las necesidades de
los interesados en el proyecto, un plan de gestión de costes puede ser formal o
informal, muy detallado o ampliamente esbozado. El plan de gestión de costes es un
plan subsidiario del plan de gestión del proyecto o una parte de él. También
conocido como: Plan de Administración de Costos; Plan de Gerencia de Costos;
Plan de Gerenciamiento de Costos; o Plan de Gestión de Costos.
Plan de Gestión de las Adquisiciones / Procurement Management Plan [Salida/Entrada].
El documento que describe cómo serán gestionados los procesos de adquisición
desde la etapa de adquisición de la documentación de adquisición hasta el cierre del
contrato. También conocido como: Plan de Administración de las Adquisiciones;
Plan de Gerencia de las Adquisiciones; o Plan de Gerenciamiento de las
Adquisiciones.
Plan de Gestión de las Comunicaciones / Communication Management Plan
[Salida/Entrada]. El documento que describe: las necesidades y expectativas de
comunicación para el proyecto; cómo y bajo qué formato se comunicará la
información; dónde y cuándo se realizará cada comunicación; y quién es el
responsable de efectuar cada tipo de comunicación. Dependiendo de las necesidades
de los interesados en el proyecto, un plan de gestión de las comunicaciones puede
ser formal o informal, muy detallado o ampliamente esbozado. El plan de gestión de
las comunicaciones es un plan subsidiario del plan de gestión del proyecto o una

230
 parte de él. También conocido como: Plan de Administración de las
Comunicaciones; Plan de Gerencia de Comunicaciones; o Plan de Gerenciamiento
de las Comunicaciones.
Plan de Gestión de Personal / Staffing Management Plan [Proceso]. El documento que
describe cuándo y cómo se cumplirán los requisitos de recursos humanos. Es un
plan subsidiario del plan de gestión del proyecto o una parte de él. Dependiendo de
las necesidades del proyecto, el plan de gestión de personal puede ser informal y
ampliamente esbozado, o formal y muy detallado. La información del plan de
gestión de personal varía según el área de aplicación y el tamaño del proyecto.
También conocido como: Plan de Administración de Personal; Plan de Gerencia de
Personal; o Plan de Gerenciamiento de Personal.
Plan de Gestión de Riesgos / Risk Management Plan [Salida/Entrada]. El documento
que describe cómo se estructurará y realizará en el proyecto la gestión de riesgos del
proyecto. Es un plan subsidiario del plan de gestión del proyecto o una parte de él.
Dependiendo de las necesidades del proyecto, el plan de gestión de riesgos puede
ser informal y ampliamente esbozado, o formal y muy detallado. La información del
plan de gestión de riesgos varía según el área de aplicación y el tamaño del
proyecto. El plan de gestión de riesgos es diferente del registro de riesgos ya que
éste contiene la lista de riesgos del proyecto, los resultados del análisis de riesgos y
las respuestas a los riesgos. También conocido como: Plan de Administración de
Riesgos; Plan de Gerencia de Riesgos; o Plan de Gerenciamiento de Riesgos.
Plan de Gestión del Alcance del Proyecto / Project Scope Management Plan
[Salida/Entrada]. El documento que describe cómo se definirá, desarrollará y
verificará el alcance del proyecto, y cómo se creará y definirá la estructura de
desglose del trabajo. Éste sirve de guía para saber cómo el equipo de dirección del
proyecto gestionará y controlará el alcance del proyecto. Es un plan subsidiario del
plan de gestión del proyecto o una parte de él. Dependiendo de las necesidades del
proyecto, el plan de gestión del alcance del proyecto puede ser informal y
ampliamente esbozado, o formal y muy detallado. También conocido como: Plan de
Administración del Alcance del Proyecto; Plan de Gerencia del Alcance del
Proyecto; o Plan de Gerenciamiento del Alcance del Proyecto.
Plan de Gestión del Contrato / Contract Management Plan [Salida/Entrada]. El
documento que describe cómo se administrará un contacto específico, que puede
incluir temas como la entrega de la documentación necesaria y los requisitos de
rendimiento. Dependiendo de las necesidades del contrato, un plan de gestión del
contrato puede ser formal o informal, muy detallado o ampliamente esbozado. Cada
plan de gestión del contrato es un plan subsidiario al plan de gestión del proyecto.
También conocido como: Plan de Administración de Contratos; Plan de
Administración del Contrato; Plan de Gerencia del Contrato; o Plan de
Gerenciamiento del Contrato.
Plan de Gestión del Cronograma / Schedule Management Plan [Salida/Entrada]. El
documento que establece los criterios y las actividades para desarrollar y controlar el
cronograma del proyecto. Es un plan subsidiario del plan de gestión del proyecto o
una parte de él. El plan de gestión del cronograma puede ser formal o informal, muy
detallado o ampliamente esbozado, según las necesidades del proyecto. También
conocido como: Plan de Administración del Cronograma; Plan de Gerencia del
Cronograma; o Plan de Gerenciamiento del Cronograma.
Plan de Gestión del Proyecto / Project Management Plan [Salida/Entrada]. Un
documento formalmente aprobado que define cómo se ejecuta, supervisa y controla

231
 un proyecto. Puede ser resumido o detallado y estar compuesto por uno o más
planes de gestión subsidiarios y otros documentos de planificación. También
conocido como: Plan de Administración del Proyecto; Plan de Gerencia del
Proyecto; Plan de Gerenciamiento de Proyectos; o Plan de la Dirección del
Proyecto.
Plan de la Cuenta de Control / Control Account Plan (CAP) [Herramienta]. Un plan
para todo el trabajo y esfuerzo que se debe realizar en una cuenta de control. Cada
CAP cuenta con enunciado del trabajo, cronograma y presupuesto de fases
definitivos. Antes se llamaba Plan de Cuentas de Costes. También conocido como:
Plan de Cuentas de Control.
Planificación de Calidad / Quality Planning [Proceso]. El proceso de identificar qué
estándares de calidad son relevantes para el proyecto y de determinar cómo
satisfacerlos. También conocido como: Planeación de Calidad.
Planificación de la Gestión de Riesgos / Risk Management Planning [Proceso]. El
proceso de decidir cómo enfrentar, planificar y ejecutar las actividades de gestión de
riesgos para un proyecto. También conocido como: Planeación de la Administración
de Riesgos; Planificación de la Administración de Riesgos; Planificación de la
Gerencia de Riesgos; o Planificación del Gerenciamiento de Riesgos.
Planificación de la Respuesta a los Riesgos / Risk Response Planning [Proceso]. El
proceso de desarrollar opciones y acciones para mejorar las oportunidades y reducir
las amenazas a los objetivos del proyecto. También conocido como: Planeación de
la Respuesta a los Riesgos.
Planificación de las Comunicaciones / Communications Planning [Proceso]. El proceso
de determinar las necesidades con respecto a la información y las comunicaciones
de los interesados en el proyecto: quiénes son, cuál es su nivel de interés e
influencia sobre el proyecto, quién necesita qué tipo de información, cuándo la
necesita y cómo se le entregará. También conocido como: Planeación de las
Comunicaciones.
Planificación de los Recursos Humanos / Human Resource Planning [Proceso]. El
proceso de identificar y documentar los roles dentro del proyecto, las
responsabilidades y las relaciones de comunicación, así como de crear el plan de
gestión de personal. También conocido como: Planeación de los Recursos
Humanos.
Planificación de Recursos / Resource Planning. Véase estimación de recursos de la
actividad. También conocido como: Planeación de Recursos.
Planificación del Alcance / Scope Planning [Proceso]. El proceso de crear un plan de
gestión del alcance del proyecto. También conocido como: Planeación del Alcance.
Planificación Gradual / Rolling Wave Planning [Técnica]. Una forma de planificación
de elaboración gradual en la que el trabajo que se debe realizar en el corto plazo se
planifica en detalle en un nivel inferior de la estructura de desglose del trabajo,
mientras que el trabajo a más largo plazo se planifica a un nivel relativamente alto
de la estructura de desglose del trabajo, pero la planificación detallada del trabajo
que se debe realizar dentro de uno o dos períodos en el futuro cercano se realiza a
medida que el trabajo se completa durante el período actual. También conocido
como: Planeación Continua con Incremento de Detalle.
Planificar la Contratación / Plan Contracting [Proceso]. El proceso de documentar los
requisitos de los productos, servicios y resultados, y de identificar a los posibles

232
 proveedores. También conocido como: Planear la Contratación o Planificación de la
Contratación.

Planificar las Compras y Adquisiciones / Plan Purchases and Acquisitions [Proceso]. El

proceso de determinar qué comprar o adquirir, y cuándo y cómo hacerlo. También
conocido como: Planear las Compras y Adquisiciones.
Plantilla / Template. Un documento parcialmente completo en un formato predefinido,
que proporciona una estructura definida para recopilar, organizar y presentar
información y datos. Las plantillas suelen basarse en documentos creados durante
proyectos anteriores. Las plantillas pueden reducir el esfuerzo necesario para
realizar un trabajo y aumentar la consistencia de los resultados.
Polémica / Issue. Un punto o asunto cuestionado o respecto del cual existe una
controversia, o que no se ha resuelto y se está analizando, o respecto del cual existen
posiciones opuestas o desacuerdo. También conocido como: Problema o Punto de
Atención.
Porcentaje Completado / Percent Complete (PC or PCT). Una estimación, expresada
como un porcentaje, de la cantidad de trabajo que se ha terminado respecto de una
actividad o un componente de la estructura de desglose del trabajo.
Portafolio / Portfolio. Una conjunto de proyectos o programas y otros trabajos que se
han agrupado para facilitar la gestión eficiente de ese trabajo, a fin de cumplir con
los objetivos estratégicos de negocio. Los proyectos o programas del portafolio no
son necesariamente interdependientes o están directamente relacionados.
Práctica / Practice. Un tipo específico de actividad profesional o de gestión que
contribuye a ejecutar un proceso y que puede utilizar una o más técnicas y
herramientas.
Preparación del Presupuesto de Costes / Cost Budgeting [Proceso]. El proceso de sumar
los costes estimados de actividades individuales o paquetes de trabajo a fin de
establecer un coste de referencia. También conocido como: Preparación del
Presupuesto de Costos o Presupuesto de Costos.
Presupuesto / Budget. La estimación aprobada para el proyecto o cualquier otro
componente de la estructura de desglose del trabajo u otra actividad del cronograma.
Véase también estimación.
Presupuesto hasta la Conclusión / Budget At Completion (BAC). La suma de todos los
valores del presupuesto establecidos para el trabajo que se realizará en un proyecto,
componente de la estructura de desglose del trabajo o actividad del cronograma. El
valor planificado total para el proyecto. También conocido como: Presupuesto a la
Terminación; Presupuesto Final; o Presupuesto hasta la Terminación.
Procedimiento / Procedure. Una serie de pasos que se siguen en un orden regular
definitivo con un propósito.
Procedimiento documentado / Documented Procedure. Una descripción formalizada por
escrito sobre cómo llevar a cabo una actividad, proceso, técnica o metodología.
Proceso / Process. El conjunto de medidas y actividades interrelacionadas realizadas
para obtener un conjunto específico de productos, resultados o servicios.
Proceso de Dirección de Proyectos / Project Management Process. Uno de los 44
procesos, propios de la dirección de proyectos que se describe en la Guía del
PMBOK®. También conocido como: Proceso de Administración de Proyectos;

233
 Proceso de Gerencia de Proyectos; Proceso de Gestión de Proyectos; o Proceso del
Gerenciamiento de Proyectos.
Proceso de un Área de Conocimiento / Knowledge Area Process. Un proceso de
dirección de proyectos identificable, dentro de un área de conocimiento.
Procesos de Cierre / Closing Processes [Grupo de Procesos]. Aquellos procesos
realizados para finalizar formalmente todas las actividades de un proyecto o fase y
transferir el producto terminado a terceros. También puede referirse a cerrar un
proyecto cancelado.
Procesos de Ejecución / Executing Processes [Grupo de procesos]. Aquellos procesos
realizados para terminar el trabajo definido en el plan de gestión del proyecto para
alcanzar los objetivos del proyecto definidos en el enunciado del alcance del
proyecto.
Procesos de Iniciación / Initiating Processes [Grupo de procesos]. Los procesos que se
llevan a cabo a fin de autorizar y definir el alcance de una nueva fase o proyecto, o
que pueden dar como resultado la reanudación del trabajo en el caso de un proyecto
interrumpido. Una gran cantidad de los procesos de iniciación habitualmente se
realiza fuera del ámbito de control del proyecto, por los procesos de la organización,
el programa o el portafolio, y dichos procesos proporcionan las entradas al grupo de
procesos de iniciación del proyecto.
Procesos de Planificación / Planning Processes [Grupo de Procesos]. Los procesos
realizados para definir y madurar el alcance del proyecto, desarrollar el plan de
gestión del proyecto e identificar y programar las actividades del proyecto* que
tengan lugar dentro del proyecto. También conocido como: Procesos de Planeación.
Procesos de Seguimiento y Control / Monitoring and Controlling Processes [Grupo de
Procesos]. Aquellos procesos realizados para medir y supervisar la ejecución de los
proyectos* de manera tal que se puedan realizar acciones correctivas cuando sea
necesario, para controlar la ejecución de la fase o proyecto. También conocido
como: Procesos de Monitoreo y Control.
Producto / Product. Un artículo producido, que es cuantificable y que puede ser un
elemento terminado o un componente. Otras palabras para hacer referencia a los
productos son materiales y bienes. Compárese con resultado y servicio. Véase
también producto entregable.
Producto Entregable / Deliverable [Salida/Entrada]. Cualquier producto, resultado o
capacidad de prestar un servicio único y verificable que debe producirse para
terminar un proceso, una fase o un proyecto. A menudo se utiliza más
concretamente en relación con un producto entregable externo, que es un producto
entregable sujeto a aprobación por parte del patrocinador del proyecto o del cliente.
Véase también producto, servicio y resultado. También conocido como: Entregable.
Profesional en la Dirección de Proyectos (PMP®) / Project Management Professional
(PMP®). Persona certificada como PMP® por el Project Management Institute
(PMI®). También conocido como: Profesional de la Gerencia de Proyectos;
Profesional de la Gestión de Proyectos; Profesional en Administración de Proyectos;
o Profesional en el Gerenciamiento de Proyectos.
Programa / Program. Un grupo de proyectos relacionados cuya gestión se realiza de
manera coordinada para obtener beneficios y control, que no se obtendrían si se
gestionaran en forma individual. Los programas pueden incluir elementos de trabajo
relacionados que están fuera del alcance de los proyectos diferenciados del
programa.

234
Proyecciones / Forecasts. Estimaciones o predicciones de condiciones y eventos futuros
para el proyecto sobre la base de la información y el conocimiento disponible en el
momento de realizar la proyección. Las proyecciones se actualizan y se emiten
nuevamente sobre la base de la información sobre el rendimiento del trabajo que se
consigue a medida que se ejecuta el proyecto. La información se basa en el
rendimiento pasado del proyecto y en el rendimiento previsto para el futuro, e
incluye información que podría ejercer un impacto sobre el proyecto en el futuro, tal
como estimación a la conclusión y estimación hasta la conclusión. También
conocido como: Pronósticos.
Proyecto / Project. Un esfuerzo temporal que se lleva a cabo para crear un producto,
servicio o resultado único.
Realizar Aseguramiento de Calidad / Perform Quality Assurance (QA) [Proceso]. El
proceso de realizar las actividades planificadas y sistemáticas de calidad (como
auditorias o revisiones por iguales) a fin de garantizar que el proyecto utiliza todos
los procesos necesarios para satisfacer los requisitos.
Realizar Control de Calidad / Perform Quality Control (QC) [Proceso]. El proceso de
supervisar los resultados específicos del proyecto para determinar si cumplen con
los estándares de calidad relevantes e identificar modos de eliminar las causas de un
rendimiento insatisfactorio.
Reclamación / Claim. Una solicitud, demanda o declaración de derechos realizada por
un proveedor contra un comprador, o viceversa, para su consideración,
compensación o pago en virtud de los términos de un contrato legalmente
vinculante, como puede ser el caso de un cambio que es objeto de disputa. También
conocido como: Reclamo.
Recorrido Hacia Adelante / Forward Pass. El cálculo de fechas de inicio tempranas y
fechas de finalización tempranas para las porciones no completadas de todas las
actividades de la red. Véase también análisis de la red del cronograma y recorrido
hacia atrás.
Recorrido Hacia Atrás / Backward Pass. Cálculo de las fechas de finalización tardías y
fechas de inicio tardías para las partes incompletas de todas las actividades del
cronograma. Se determina yendo hacia atrás en la lógica de la red del cronograma a
partir de la fecha de conclusión del proyecto, la que puede calcularse en un recorrido
hacia adelante o ser establecida por el cliente o patrocinador. Véase también análisis
de la red del cronograma.
Recurso / Resource. Recursos humanos especializados (disciplinas específicas, ya sea
en forma individual, o en equipos o grupos), equipos, servicios, suministros,
materias primas, materiales, presupuestos o fondos.
Red / Network. Véase diagrama de red de cronograma del proyecto.
Registro / Log. Un documento que se utiliza para registrar y describir o indicar los
elementos seleccionados identificados durante la ejecución de un proceso o
actividad. Habitualmente se utiliza con un modificador, tal como problemas, control
de calidad, acciones o defectos. También conocido como: Bitácora.
Registro de Riesgos / Risk Register [Salida/Entrada]. El documento que contiene los
resultados del análisis cualitativo de riesgos, análisis cuantitativo de riesgos y
planificación de la respuesta a los riesgos. El registro de riesgos detalla todos los
riesgos identificados, incluso la descripción, categoría, causa, probabilidad de
ocurrencia, impactos en los objetivos, respuestas propuestas, responsables y

235
 condición actual. El registro de riesgos es un componente del plan de gestión del
proyecto.
Reglas Básicas / Ground Rules [Herramienta]. Una lista de comportamientos aceptables
e inaceptables adoptados por un equipo del proyecto con el fin de mejorar las
relaciones laborales, la efectividad y la comunicación.
Regulación / Regulation. Requisitos impuestos por una entidad gubernamental. Estos
requisitos pueden establecer las características del producto, del proceso o del
servicio, incluidas las disposiciones administrativas aplicables de obligado
cumplimiento exigido por el gobierno.
Relación de Precedencia / Precedence Relationship. El término usado en el método de
diagramación por precedencia para una relación lógica. Sin embargo, en el uso
corriente, la relación de precedencia, la relación lógica y la dependencia son
conceptos sumamente intercambiables, independientemente del método de
diagramación.
Relación Lógica / Logical Relationship. Una dependencia entre dos actividades del
cronograma del proyecto, o entre una actividad del cronograma del proyecto y un
hito del proyecto. Véase también relación de precedencia. Los cuatro tipos posibles
de relaciones lógicas son: Fin a Inicio; Fin a Fin; Inicio a Inicio; e Inicio a Fin.
Reparación de Defectos / Defect Repair. Identificación formalmente documentada de un
defecto en un componente de un proyecto, con una recomendación de reparar dicho
defecto o reemplazar completamente el componente.
Reproceso / Rework. Acción realizada para que un componente defectuoso o que no
responda a los requisitos o especificaciones los cumpla. También conocido como:
Retrabajo.
Requisito / Requirement. Una condición o capacidad que un sistema, producto, servicio,
resultado o componente debe satisfacer o poseer para cumplir con un contrato,
norma, especificación u otros documentos formalmente impuestos. Los requisitos
incluyen las necesidades, deseos y expectativas cuantificadas y documentadas del
patrocinador, del cliente y de otros interesados. También conocido como:
Requerimiento.
Reserva / Reserve. Provisión de fondos en el plan de gestión del proyecto para mitigar
riesgos del cronograma y/o costes. Se utiliza a menudo con un modificador (por ej.,
reserva de gestión, reserva para contingencias) con el objetivo de proporcionar más
detalles sobre qué tipos de riesgos se pretende mitigar. El significado específico del
término modificado varía por área de aplicación.
Reserva para Contingencias / Contingency Reserve [Salida/Entrada]. La cantidad de
fondos, presupuesto o tiempo, que supere la estimación, necesarios para reducir el
riesgo de sobrecostes de los objetivos del proyecto a un nivel aceptable para la
organización.
Restricción / Constraint [Dato Inicial]. El estado, la calidad o la sensación de ser
restringido a un curso de acción o inacción determinado. Una restricción o
limitación aplicable, ya sea interna o externa al proyecto, que afectará el
rendimiento del proyecto o de un proceso. Por ejemplo, una restricción del
cronograma consiste en una limitación o condicionamiento aplicado sobre el
cronograma del proyecto que afecta el momento en el que una actividad del
cronograma puede programarse y que suele presentarse bajo la forma de fechas
impuestas fijas. Una restricción en el coste es cualquier limitación o
condicionamiento aplicado sobre el presupuesto del proyecto tales como fondos

236
 disponibles a lo largo del tiempo. Una restricción de recursos del proyecto es
cualquier limitación o condicionamiento aplicado sobre el uso de un recurso como,
por ejemplo, qué tipo de recursos de habilidades o disciplinas hay disponibles, y la
cantidad disponible de un recurso determinado durante un período específico.
Resultado / Result. Una salida de la ejecución de procesos y actividades de dirección de
proyectos. Los resultados incluyen consecuencias (por ej., sistemas integrados,
procesos revisados, organización reestructurada, pruebas, personal capacitado, etc.)
y documentos (por ej., políticas, planes, estudios, procedimientos, especificaciones,
informes, etc.). Compárese con producto y servicio. Véase también producto
entregable.
Retención / Retainage. Parte del pago de un contrato que se retiene hasta su conclusión
para garantizar el pleno cumplimiento de los términos del contrato.
Retraso / Lag [Técnica]. Una modificación de una relación lógica que causa un retraso
en la actividad sucesora. Por ejemplo, en una dependencia de final a inicio con un
retraso de diez días, la actividad sucesora no puede comenzar hasta diez días
después del final de la actividad predecesora. Véase también adelanto. También
conocido como: Demora o Posposición.
Reubicación / Co-location [Técnica]. Una estrategia de ubicación de la organización en
virtud de la cual se acercan físicamente los miembros del equipo del proyecto para
mejorar la comunicación, las relaciones laborales y la productividad. También
conocido como: Co-localización; Concentración; Reagrupamiento; Ubicación
Cercana; o Ubicar.
Revisión del Diseño / Design Review [Técnica]. Una técnica de gestión que se utiliza
para evaluar un diseño propuesto a fin de asegurar que el diseño del sistema o
producto cumpla con los requisitos del cliente, o para asegurar que el diseño
funcionará correctamente y que se puede producir y mantener.
Riesgo / Risk. Un evento o condición incierta que, si se produce, tiene un efecto
positivo o negativo en los objetivos de un proyecto. Véase también categoría de
riesgo y estructura de desglose del riesgo.
Riesgo Residual / Residual Risk. Riesgo que permanece después de haber
implementado las respuestas a los riesgos.
Riesgo Secundario / Secondary Risk. Un riesgo que surge como resultado directo de la
implantación de una respuesta a los riesgos.
Rol / Role. Una función definida que debe realizar un miembro del equipo del proyecto,
como evaluar, archivar, inspeccionar o codificar.
Salida / Output [Salida del Proceso]. Un producto, resultado o servicio generado por un
proceso. Puede ser un dato inicial para un proceso sucesor. También conocido
como: Resultado.
Seguimiento / Monitoring. Véase realizar seguimiento. También conocido como:
Monitorear o Monitoreo.
Seguimiento y Control de Riesgos / Risk Monitoring and Control [Proceso]. El proceso
de realizar el seguimiento de los riesgos identificados, monitorizar los riesgos
residuales, identificar nuevos riesgos, ejecutar planes de respuesta a los riesgos y
evaluar su efectividad durante todo el ciclo de vida del proyecto. También conocido
como: Monitoreo y Control de Riesgos.

237
Selección de Proveedores / Select Sellers [Proceso]. El proceso de analizar ofertas,
seleccionando entre posibles proveedores y negociando un contrato por escrito con
un proveedor. También conocido como: Selección de Proveedores.
Servicio / Service. Trabajo útil realizado que no produce un producto ni un resultado
tangible, por ejemplo, llevar a cabo cualquiera de las funciones del negocio que
respaldan la producción o la distribución. Compárese con producto y resultado.
Véase también producto entregable.
Simulación / Simulation. Una simulación usa un modelo de proyecto que traduce las
incertidumbres especificadas a un nivel detallado a su impacto posible en los
objetivos, que están expresados para el proyecto total. Las simulaciones de
proyectos usan modelos informáticos y estimaciones de riesgo, que, generalmente,
se expresan como una distribución de probabilidad de costes o duraciones posibles a
un nivel de trabajo detallado y, normalmente, se realizan usando el análisis Monte
Carlo.
Sistema / System. Un conjunto integrado de componentes interdependientes o que
interactúan regularmente, creado para alcanzar un objetivo definido, con relaciones
definidas y continuas entre sus componentes, que al formar un todo produce y
funciona mejor que la simple suma de sus componentes. Los sistemas pueden estar
basados en un proceso físico, en un proceso de gestión, o lo que es más común, en
una combinación de ambos. Los sistemas para la dirección de proyectos están
formados por procesos, técnicas, metodologías y herramientas de dirección de
proyectos operadas por el equipo de dirección del proyecto.
Sistema de Autorización de Trabajo / Work Authorization System [Herramienta]. Un
subsistema del sistema de gestión de proyectos general. Es un conjunto de
procedimientos formalmente documentados que define cómo se autorizará el
proyecto de trabajo (comprometido) para garantizar que la organización identificada
realice el trabajo en el tiempo asignado y con la secuencia correcta. Incluye los
pasos, documentos, sistema de seguimiento, y niveles de aprobación definidos
necesarios para emitir las autorizaciones de trabajo.
Sistema de Control de Cambios / Change Control System [Herramienta]. Un conjunto
de procedimientos formalmente documentados que definen cómo se controlarán,
cambiarán y aprobarán los productos entregables, y cualquier otra documentación
del proyecto. En la mayoría de las áreas de aplicación, el sistema de control de
cambios es un subconjunto del sistema de gestión de la configuración.
Sistema de Gestión de la Configuración / Configuration Management System
[Herramienta]. 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 implantación; y 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 seguimiento, y los niveles de
aprobación definidos necesarios para autorizar y controlar los cambios. En la
mayoría de las áreas de aplicación el sistema de gestión de la configuración incluye
el sistema de control de cambios. También conocido como: Sistema de
Administración de la Configuración; Sistema de Gerencia de Configuración; o
Sistema de Gerenciamiento de la Configuración.

238
Sistema de Gestión de Proyectos / Project Management System [Herramienta]. La suma
de los procesos, herramientas, técnicas, metodologías, recursos y procedimientos
necesarios para gestionar un proyecto. El sistema queda documentado en el plan de
gestión del proyecto y su contenido variará dependiendo del área de aplicación,
influencia de la organización, complejidad del proyecto y disponibilidad de los
sistemas existentes. Un sistema de gestión de proyectos, que puede ser formal o
informal, ayuda al director del proyecto a liderar un proyecto de forma efectiva
hasta su cierre. Un sistema de gestión de proyectos es un conjunto de procesos y
funciones de supervisión y control relacionados, que se consolidan y combinan en
un todo funcional y unificado. También conocido como: Sistema de Administración
de Proyectos; Sistema de Dirección de Proyectos; Sistema de Gerencia de
Proyectos; o Sistema de Gerenciamiento de Proyectos.
Sistema de Información de la Gestión de Proyectos / Project Management Information
System (PMIS) [Herramienta]. Un sistema de información compuesto por
herramientas y técnicas utilizado para recabar, 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. También conocido como: Sistema de Información de la
Administración de Proyectos; Sistema de Información de la Dirección de Proyectos;
Sistema de Información de la Gerencia de Proyectos; Sistema de Información del
Gerenciamiento de Proyectos; o Sistema de Información para la Administración de
Proyectos.
Software de Gestión de Proyectos / Project Management Software [Herramienta]. Una
clase de aplicación de software para ordenadores diseñada especialmente para
ayudar al equipo de dirección de proyectos en la planificación, seguimiento y
control del proyecto, incluidos: estimación de costes, planificación, comunicaciones,
colaboración, gestión de la configuración, control de documentos, gestión de
registros y análisis de riesgos. También conocido como: Software de
Administración de Proyectos; Software de Dirección de Proyectos; Software de
Gerencia de Proyectos; o Software de Gerenciamiento de Proyectos.
Solicitar Respuestas de Proveedores / Request Seller Responses [Proceso]. El proceso
de obtener información, presupuestos, licitaciones, ofertas o propuestas, según
corresponda. También conocido como: Solicitar Respuesta de Proveedores o
Solicitar Respuestas de Proveedores.
Solicitud de Cambio / Change Request. Solicitudes para ampliar o reducir el alcance de
un proyecto, modificar políticas, procesos, planes o procedimientos, modificar
costes o presupuestos, o revisar cronogramas. Las solicitudes de cambio pueden
hacerse directa o indirectamente, pueden iniciarse en forma externa o interna y
pueden tener carácter obligatorio u opcional, ya sea desde el punto de vista legal o
contractual. Únicamente se procesan las solicitudes de cambio formalmente
documentadas, y sólo se implementan las solicitudes de cambio aprobadas.
Solicitud de Cambio Aprobada / Approved Change Request [Salida/Entrada]. Una
solicitud de cambio que se ha procesado a través del proceso de control de cambio
integrado y que ha sido aprobada. Compárese con cambio solicitado.
Solicitud de Información / Request for Information. Un tipo de documento de
adquisición por el cual el comprador solicita al posible proveedor que proporcione
determinada información relacionada con un producto, servicio o capacidad del
proveedor.

239
Solicitud de Presupuesto / Request for Quotation (RFQ). Un tipo de documento de
adquisición que se utiliza para solicitar presupuestos de precio a posibles
proveedores de productos o servicios comunes o estándar. A veces se utiliza en
lugar de la solicitud de propuesta y en algunas áreas de aplicación, es posible que
tenga un significado más limitado o específico. También conocido como: Pedido de
Cotización o Solicitud de Cotización.
Solicitud de Propuesta / Request for Proposal (RFP). Un tipo de documento de
adquisición que se utiliza para solicitar propuestas de posibles proveedores de
productos o servicios. En algunas áreas de aplicación puede tener un significado
más limitado o específico.
Solución Alternativa / Workaround [Técnica]. Una respuesta a un riesgo negativo que
se ha producido. Se distingue del plan para contingencias, ya que no hay una
solución alternativa planificada de forma anticipada al evento de riesgo.
Subfase / Subphase. Una subdivisión de una fase.
Subproyecto / Subproject. Una porción más pequeña del proyecto general creada al
subdividir un proyecto en componentes o partes más fáciles de gestionar.
Generalmente, los subproyectos están representados en una estructura de desglose
del trabajo. Un subproyecto puede ser considerado como un proyecto, gestionado
como un proyecto y adquirido a un proveedor. Puede ser considerado una subred en
un diagrama de red del cronograma del proyecto.
Subred / Subnetwork. Una subdivisión (fragmento) de un diagrama de red del
cronograma del proyecto que, por lo general, representa un subproyecto o un
paquete de trabajo. A menudo se utiliza para ilustrar o estudiar una condición del
cronograma posible o propuesta, por ejemplo, cambios en la lógica preferencial del
cronograma o en el alcance del proyecto. También conocido como: Subsistema de
red.
Sucesora / Successor. Véase actividad sucesora.
Supervisar / Monitor. Recolectar datos de rendimiento del proyecto con respecto a un
plan, producir medidas de rendimiento, e informar y difundir la información sobre el
rendimiento. También conocido como: Monitorear.
Supervisar y Controlar el Trabajo del Proyecto / Monitor and Control Project Work
[Proceso]. El proceso de supervisar y controlar los procesos requeridos para iniciar,
planificar, ejecutar y cerrar un proyecto, a fin de cumplir con los objetivos de
rendimiento definidos en el plan de gestión del proyecto y el enunciado del alcance
del proyecto. También conocido como: Monitorear y Controlar el Trabajo del
Proyecto.
Tarea / Task. Un término que reemplaza a trabajo, cuyo significado y ubicación dentro
de un plan estructurado para un trabajo del proyecto varía de acuerdo con el área de
aplicación, industria y marca del software de gestión de proyectos.
Técnica / Technique. Un procedimiento sistemático definido y utilizado por una persona
para realizar una actividad para producir un producto o un resultado, o prestar un
servicio, y que puede emplear una o más herramientas.
Técnica del Valor Ganado / Earned Value Technique (EVT) [Técnica]. Una técnica
específica para medir el rendimiento del trabajo para un componente de la estructura
de desglose del trabajo, una cuenta de control o un proyecto. También conocido
como: Método de Acreditación; Normas de Devengo; o Técnica del Valor del
Trabajo Realizado.

240
Técnica Delphi / Delphi Technique [Técnica]. Una técnica para recabar información que
se utiliza como método para lograr el consenso de 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. La técnica Delphi ayuda a reducir sesgos
en los datos y evita que cualquier persona ejerza influencias impropias en el
resultado.
Tormenta de Ideas / Brainstorming [Técnica]. Una técnica general de recolección de
datos y creatividad que puede usarse para identificar riesgos, ideas o soluciones a
problemas mediante el uso de un grupo de miembros del equipo o expertos en el
tema. Generalmente, una sesión de tormenta de ideas consiste en registrar las
opiniones de cada participante para su posterior análisis. También conocido como:
Lluvia de Ideas.
Trabajo / Work. Esfuerzo físico o mental, empleo o ejercicio de una habilidad en forma
sostenida, para superar obstáculos y lograr un objetivo.
Trabajo del Proyecto / Project Work. Véase trabajo.
Transferir el Riesgo / Risk Transference [Técnica]. Una técnica de planificación de la
respuesta a los riesgos* que traslada el impacto de una amenaza a un tercero, junto
con la responsabilidad de la respuesta. También conocido como: Transferencia del
Riesgo.
Triple Restricción / Triple Constraint. Un marco para evaluar demandas contrapuestas.
La triple restricción suele representarse como un triángulo en el cual uno de los
lados, o de los vértices, representa uno de los parámetros que gestiona el equipo de
proyecto.
Última Estimación Revisada / Latest Revised Estimate. Véase estimación al término.
Umbral / Threshold. Un valor de coste, tiempo, calidad, técnico o de recurso utilizado
como parámetro, y que puede incluirse en las especificaciones del producto. Superar
el umbral disparara alguna medida, como generar un informe por excepción.
Unidad de Calendario / Calendar Unit. La unidad de tiempo más pequeña utilizada en la
planificación del proyecto. Por lo general, las unidades calendario se expresan en
horas, días o semanas, pero también pueden expresarse en términos de trimestres,
meses, turnos y hasta minutos.
Usuario / User. La persona u organización que usará el producto o servicio del proyecto.
Véase también cliente.
Validación / Validation [Técnica]. La técnica para evaluar un componente o producto
durante una fase o proyecto, o al finalizar los mismos, a fin de garantizar que
cumpla con los requisitos especificados. Compárese con verificación.
Valor Ganado / Earned Value (EV). El valor del trabajo completado expresado en
términos del presupuesto aprobado asignado a dicho trabajo para una actividad del
cronograma o un componente de la estructura de desglose del trabajo. También
conocido como: Coste Presupuestado del Trabajo Realizado o Valor Devengado.
Valor Planificado / Planned Value (PV). El presupuesto autorizado asignado al trabajo
planificado que debe realizarse respecto de una actividad del cronograma o
componente de la estructura de desglose del trabajo. También conocido como Coste
Presupuestado del Trabajo Planificado o Valor Planeado.

241
Variación / Variance. Una desviación, cambio o divergencia cuantificable de una
referencia conocida o valor previsto.
Variación del Coste / Cost Variance (CV). Una medida de rendimiento en función de
los costes con respecto a un proyecto. Es la diferencia algebraica entre el valor
ganado (EV) y el coste real (AC). CV = EV menos AC. Un valor positivo indica una
condición favorable, y un valor negativo indica una condición desfavorable.
También conocido como: Variación del Costo o Variación en los Costos.
Variación del Cronograma / Schedule Variance (SV). Una medida de rendimiento del
cronograma en un proyecto. Es una diferencia algebraica entre el valor ganado
(EV) y el valor planificado (PV). SV = EV menos PV. Véase también gestión del
valor ganado. También conocido como: Variación en Tiempo.
Proveedor / Seller. Un distribuidor o proveedor de productos, servicios o resultados de
una organización. También conocido como: Proveedor.
Verificación / Verification [Técnica]. La técnica de evaluar un componente o producto
al final de una fase o proyecto para asegurar o confirmar que cumple con las
condiciones impuestas. Compárese con validación.
Verificación del Alcance / Scope Verification [Proceso]. El proceso de formalizar la
aceptación de los productos entregables terminados del proyecto.

242
ANEXO A: DOCUMENTACIÓN DEL CASO DE
MIGRACIÓN DE TECNOLOGÍAS:

A.1 INTRODUCCIÓN A LAS REDES HFC:

La red HFC está formada por un tramo de transporte de fibra óptica y un tramo de
acceso de cable coaxial. Surge como una evolución de las redes de cable todo coaxial,
es decir, aquellas en que se utiliza el cable coaxial como único medio de transmisión.

La fibra óptica presenta un conjunto de ventajas respecto al cable coaxial: mayor ancho
de banda, mayor inmunidad al ruido y a las interferencias, y menor atenuación. Todas
estas características hacen de la fibra óptica un medio físico idóneo para la transmisión
de señales. Es por ello que la red de cable todo coaxial evoluciona hacia una red híbrida
que combina el uso del cable coaxial con el uso de fibra óptica. El siguiente esquema
representa la estructura básica de una red HFC:

Gráfico 26: Estructura básica de red HFC

La cabecera es el primer elemento de la red. Contiene el equipo necesario para recibir

las diferentes señales, procesarlos y transmitirlos; diferentes interfaces de comunicación
con proveedores y redes externas; y elementos de gestión y control del funcionamiento
global de la red. El conjunto de señales se transmite a través de la red troncal, que está
constituida por canalizaciones de fibra óptica hacia diversos nodos óptico-electrónicos
(NOE). En ellos, la señal óptica recibida se convierte en señal eléctrica, de manera que
puede ser transportada a través del cable coaxial hacia las casas de los usuarios.

A medida que el tamaño de la red crece, se hace necesaria una segmentación más
compleja, que permita la distribución de las señales hacia grupos de usuarios no
demasiado grandes. Se introduce así el concepto de centro nodal (Hub) que se instala en
el tramo de fibra óptica, es decir, tanto la señal de entrada como la de salida son ópticas.
Las funciones básicas del centro nodal son la amplificación de las señales recibidas y la
distribución de estas hacia diferentes fibras ópticas que alimentan a sus respectivos
nodos óptico-electrónicos. El esquema de dicha estructura segmentada es el siguiente:

Gráfico 27: Estructura segmentada de red HFC

243
Como ya se comentó, la red HFC surge como una evolución de la red de cable todo
coaxial. En una primera etapa de evolución, se utiliza la fibra óptica para cubrir los
tramos de larga longitud de la red y que presenten pocas ramificaciones, y continúa
empleándose el coaxial para los tramos finales, que son más cortos y con mayores
ramificaciones. Con la utilización de la fibra óptica en los tramos largos se consigue
reducir la atenuación introducida, de manera que se eliminan los amplificadores que
eran necesarios en la red todo coaxial, y consecuentemente, se reduce el ruido y las no
linealidades introducidas en la red. En sucesivas evoluciones se aumenta el tramo
cubierto de fibra óptica o, dicho de otra manera, se aumenta la proximidad del nodo
óptico-electrónico al usuario, dando paso a la existencia de diferentes estructuras de la
red HFC:
• Fiber To The Curb (FTTC) o fibra a la acera: La fibra óptica llega hasta un
punto de la acera, de manera que el tramo coaxial distribuye la señal primero
hacia diferentes edificios y, posteriormente, hacia las diferentes hogares.
• Fiber To The Building (FTTB) o fibra al edificio: La fibra óptica llega hasta
cada uno de los edificios, los cuales contienen su propio nodo óptico-electrónico.
El tramo de coaxial distribuye la señal hacia los diferentes hogares dentro del
edificio.
• Fiber To The Home (FTTH) o fibra a la casa: La fibra óptica llega hasta cada
una de las casas de los usuarios. Con el desarrollo de los equipos de usuario con
diversas entradas ópticas, puede eliminarse la figura del nodo, de manera que se
constituiría una red 100% óptica.

A.2 DESCRIPCIÓN FUNCIONAL DE LA RED HFC:

Para analizar el funcionamiento de una red HFC es conveniente analizar por separado
los dos sentidos de la comunicación. Por un lado está el conjunto de señales que parten
de la cabecera y que son conducidos a través de la red hasta la casa del usuario: Es lo
que se conoce como canal descendente. Por otro lado, está el conjunto de señales que
viajan en el sentido contrario, desde las casas de los usuarios hacia la cabecera: Se
denomina canal ascendente.

El canal descendente permite la comunicación Broadband y Narrowband (Banda ancha

y angosta, respectivamente), y por lo tanto el conjunto de servicios que se puede ofrecer
utilizándolos son los mismos que pueden ofrecerse con las redes de comunicación vía
satélite y de comunicación terrestre (Video y audio analógico, video y audio digital,
televisión de alta definición). La ventaja diferencia que aporta la red HFC respecto a
estas dos anteriores, es su canal ascendente, que constituye una conexión física
permanente entre usuarios y cabecera, fácil de usar, de gran velocidad y bajo costo. Para
facilitar la transmisión conjunta de los dos sentidos de la comunicación, se les asignan
diferentes márgenes de frecuencia, y su asignación en Europa es la siguiente:

Gráfico 28: Frecuencias de subida y bajada para HFC en Europa

244
Se utilizan las bajas frecuencias comprendidas entre los 15 y 65 MHz para el canal
ascendente o de retorno, mientras que el canal descendente se le asigna el margen
frecuencia comprendido entre los 86 y 860 MHz. La red HFC es entonces una red
bidireccional asimétrica, ya que se asignan anchos de banda diferentes a los dos sentidos
de la comunicación. A continuación se presenta un esquema simplificado que refleja la
bidireccionalidad de la red:

Gráfico 29: Esquema de la bidireccionalidad de la red HFC

En este esquema se representa una práctica habitual: El uso de fibra óptica dedicada
para cada sentido de la comunicación, y la compartición de la parte coaxial por ambos
sentidos. Los elementos clave que permiten esta compartición son los diplexores
situados dentro de las estaciones amplificadoras. Los diplexores están constituidos por
un par de filtros (paso-bajo y paso-alto) que gracias a la asignación frecuencial
previamente comentada, permiten la separación de ambos sentidos de la comunicación.

Desde sus inicios, el diseño de las redes HFC se centraron en la explotación del canal
descendente, ya que la función de la red era la transmisión Broadcast de canales de
televisión. Uno de los primeros usos que se asignaron al canal de retorno fue la
transmisión de peticiones de ‘pagar para ver’. Otro uso inicial del canal de retorno es la
transmisión de señales desde diferentes puntos hacia la cabecera, que permiten al
operador monitorear el estado de la red.

Cuando el canal de retorno sólo se usa para transmitir comandos de ‘pagar para ver’ y/o
señales para monitoreo, los requerimientos son bajos: Resulta suficiente la utilización
de un protocolo ‘Store & Forward’: Los equipos de usuario almacenan los comandos y
los transmiten hacia la cabecera cuando ésta lo solicita. Utilizando este tipo de
protocolo, el canal ascendente se usa por un único usuario en cada instante de tiempo,
de manera que este puede transmitir con una potencia suficientemente elevada como
para minimizar los efectos del ruido. Además, como los requerimientos de tiempo y

245
ancho de banda son mínimos, pueden usarse velocidades de transmisión bajas y
modulaciones poco eficientes espectralmente. A medida que aumenten los servicios y el
nivel de interactividad, estos se ven obligados a compartir el canal de retorno. Cada uno
de ellos tiene sus requerimientos de ancho de banda, de velocidad de transmisión, y de
calidad, cosa que hace necesario la introducción de otros esquemas de modulación, y
mecanismos de control y de establecimiento de niveles de potencia asignados a cada
servicio.

Como ya se mencionó, la explotación del canal ascendente de la red HFC es factor

diferenciador que da un valor añadido a esta red respecto a las de televisión terrestre y
por satélite. El nivel de interactividad que puede proporcionarse con HFC es mucho más
elevado, ya que incluye un camino físico de retorno que está permanentemente
conectado y en comunicación con la cabecera, y por lo tanto, con los diferentes
proveedores de servicios.

A.3 DIMENSIONADO DE LA RED HFC:

A la hora de diseñar una red HFC, existen dos factores principales que limitan su
dimensionado: El ruido y el ancho de banda.

Conceptos básicos: A la hora de dimensionar una red, el operador se encuentra con un

compromiso de requerimientos. Para garantizar el servicio a todos los usuarios actuales
y futuros, se debe sobredimensionar la red de manera que se pueda evolucionar a
medida que se aumentos el número de clientes. Para mantener al máximo el costo de la
red, el operador intentará no instalar más dispositivos de los necesarios. Entonces, el
operador corre peligro que un entusiasmo inicial excesivo comporte un exceso de
inversión, o que una prudencia excesiva acabe con la implantación de una red estática,
incapaz de crecer para acoger nuevas demandas de usuarios. Para no caer en ninguno de
estos extremos, se debe aplicar criterios realistas, basados en los siguientes conceptos:
• Hogares pasados: El concepto de hogares pasados hace referencia al número de
hogares que se encuentran en la zona geográfica cubierta por la red del operador.
• Penetración del cable: Habrán edificios pertenecientes a la zona de cobertura de
la red del operador que no desearán el servicio, por tanto no permitirán la
instalación de dispositivos en sus edificios. Además, de los edificios que
permiten la instalación de los dispositivos, no todos los hogares contratarán
servicios del operador. El porcentaje de hogares que contraten el servicio del
operador constituye el factor de penetración del cable.
• Penetración de los servicios: No todos los clientes de la red contratan todos los
servicios, sino que para cada servicio en concreto habrá un porcentaje de clientes
totales que los contraten.
• Simultaneidad de uso: No todos los usuarios suscritos a un servicio hacen uso
simultáneamente. Esto permite al operador establecer contratos con más usuarios
de los que realmente puede asumir la red por motivos de ancho de banda.
• Clientes efectivos: Es el número real de clientes de la red, es decir, el producto
del número de hogares pasados por el factor de penetración del cable. También
se puede hablar de clientes efectivos de un servicio en concreto, de manera que
se hace referencia a los clientes efectivos multiplicados por el factor de
penetración de este servicio.

246
Evidentemente ninguno de estos conceptos tiene valor fijo o conocido: Se deberán
estimar cada uno de ellos, contemplando la posible evolución a medio plazo.

El ruido: Hay tres factores que afectan este dimensionado:

• El número de hogares pasados cubiertos por el NOE: Cuan más grande sea el
número de hogares pasados, más grande será el número de usuarios efectivos, y
por tanto, más aumentará el ruido combinado en la etapa de radiofrecuencia. Por
otro lado, cuan más grande sea el número de hogares pasados, más
ramificaciones y amplificaciones presentará el tramo de coaxial, y por tanto
aumentará también el ruido térmico introducido a la red.
• El factor de penetración del cable: Cuan más elevado sea el factor de
penetración, más usuarios efectivos estarán conectados a la red, y por ende, más
usuarios estarán introduciendo ruido.
• El ruido de ingreso de cada usuario: Cuan más elevado sea el ruido que se
inserte en la red por cada usuario, más aumentará la combinación total de los
diferentes ruidos.

El ancho de banda: Las señales descendentes pueden ser clasificadas según el alcance
de los destinatarios: Si la señal es enviada a todos los usuarios de la red, se está
transmitiendo un servicio Broadcast (BC); por el contrario, si el destinatario de la señal
es un usuario o un grupo reducido de usuarios, el servicio es Narrowcast (NC). Los
servicios Narrowcast sobretodo, pero también los de Broadcast, requieren cada vez más
interacción por parte de los usuarios, es decir, comunicación en sentido ascendente. Por
tal de gestionar las diferentes señales (ascendente y descendente) generados para cada
uno de los servicios de Narrowcast, se emplean los servidores de aplicaciones. Son
equipos que gestionen los tráficos generados y comunican a los usuarios, si cabe, con
los proveedores de servicios. Como ejemplos de estos servicios se tienen:
• Telefonía: Su señal descendente es del tipo Narrowcast, ya que se dirige a un
único usuario. El tráfico generado por este servicio es bidireccional y simétrico,
ya que se emplea el mismo ancho de banda en ambos sentidos. Los equipos
asociados a este servicio son:
o Terminales telefónicos de usuario.
o Voice Ports (VP) o puertos de voz, que realizan la conversión de
interfaces entre coaxial de la red HFC y el par de cobre que requieren las
terminales de usuario.
o Host Digital Terminals (HDT), que conectan la red HFC con la central
de conmutación, convirtiendo la señal RF a apta para la interface V5.2.

Gráfico 30: Red HFC para telefonía

• Acceso a internet: El servicio de acceso a internet es también Narrowcast ya que

cada usuario solicita la descarga de diferentes páginas. El tráfico generado es
asimétrico, y los equipos asociados al servicio son los siguientes:
o Ordenadores.

247
 o Cablemodems (CM) o módems de cable, que realizan la conversión de
interfaces entre el coaxial de la red HFC y la interfaz del ordenador
(Ethernet o USB).
o Cabeceras de los cablemodems (CMTS), que conectan la red HFC con la
red IP y el proveedor de acceso a internet.

Gráfico 31: Red HFC para acceso a internet

• Video bajo demanda: Cada usuario solicita ver una película diferente, en
diferentes instantes de tiempo y hace acciones diferentes sobre la reproducción,
por tanto, constituye también el servicio Narrowcast. El tráfico generado es
asimétrico y el equipamiento asociado es:
o Televisión.
o Set Top Box (STB) o decodificador de televisión, que realiza la
conversión entre el coaxial de la red HFC y la interfaz de la televisión
(Conector IEC, euroconector).
o Servidores de video bajo demanda, que contienen diferentes copias de las
películas ofrecidas.

Gráfico 32: Red HFC para video bajo demanda

La combinación que se deberá hacer para transportar conjuntamente los dos tipos de
servicios en el sentido descendente hacia los usuarios, requiere la asignación de
márgenes frecuenciales diferenciados para cada uno de ellos. El gráfico a continuación
recoge un ejemplo de asignación:

Gráfico 33: Frecuencias para Broadcast y Narrowcast de HFC

Como se ha podido ver, las redes HFC fueron diseñadas inicialmente para transportar
servicios unidireccionales, desde la cabecera hacia los usuarios. Como consecuencia, el
ancho de banda dedicado a las señales en el sentido ascendente es limitado. La
limitación se hace más crítica a medida que aumenta la interactividad de los servicios.
Hay diferentes factores que hay que tener en cuenta:
• El número de hogares pasados cubiertos por el NOE.
• Factores de penetración:

248
 o Factor de penetración del cable.
o Factor de penetración de los servicios.
o Factor de simultaneidad.
• Número de servicios ofrecidos.
• Ancho de banda necesario para cada servicio.
• Técnicas de reutilización del canal de retorno.

Para el dimensionado en función del ruido, se ha de tener en cuenta únicamente el factor

de penetración del cable ya que cualquier usuario conectado físicamente a la red,
independientemente de los servicios que éste tenga contratados e independientemente
que se haga uso o no, constituye una fuente de ruido. Cuando el dimensionado se hace
en función del ancho de banda, se debe tener en cuenta que un cliente conectado a la red
sólo consume ancho de banda si está haciendo uso de los servicios, ya que el ancho de
banda se asigna dinámicamente. De esta manera se debe tener en cuenta los tres factores
de penetración (Cable, servicio y simultaneidad).

A.4 TÉCNICAS DE MEJORA:

A.4.1 Fibra óptica dedicada:

Canal descendente: Como ya se ha introducido en el apartado anterior, se asignan

márgenes frecuenciales diferenciados a los servicios Narrowcast y Broadcast, tanto en el
canal ascendente como descendente. Analizando en margen frecuencial asignados a los
servicios Narrowcast de forma análoga al análisis hecho para el canal de retorno, se
concluye que se debe emplear también para este margen, técnicas que permitan su
utilización. Una primera técnica que permite su reutilización es el uso de la fibra óptica
dedicada a cada centro nodal. El uso de fibra óptica dedicada según la estructura
analizada en anillo con redundancia de caminos, permite dedicar el ancho de banda total
dedicado a Narrowcast a un único centro nodal. Así pues, a la hora de diseñar la red
troncal surgen dos alternativas de diseño:
• Dedicar la fibra óptica (redundancia aparte) a cada centro nodal para los
servicios de narrowcast y combinar esta señal con la de Broadcast distribuida en
todos los centros nodales a través de una misma fibra.
• Transmitir las señales Narrowcast y Broadcast combinadas desde la cabecera
hacia los centros nodales, utilizando una única fibra óptica (redundancia aparte)
por centro nodal. Esta segunda solución permite reducir el número de fibras del
canal descendente a la mitad.

Canal de retorno: Se debe emplear como mínimo una fibra óptica dedicada al canal
ascendente para cada centro nodal, o dos si se desea también redundancia de caminos.
De esta manera, las diferentes señales de retorno provenientes de los diferentes nodos
que pertenecen a un mismo nodo central, son combinadas e inyectadas en una única
fibra óptica desde el centro nodal hacia la cabecera. Para llevar a cabo esta
combinación, los usuarios pertenecientes a un mismo nodo comparten, mediante
técnicas de multiplexación por división en el tiempo, una fracción del ancho de banda
total asignado al canal de retorno ΔBdaretorn/m, siguiendo el esquema del siguiente
gráfico:

249
 Gráfico 34: Multiplexación por división en el tiempo en el canal de retorno

Con tal de reducir la limitación que supone el estrecho ancho de banda dedicado a canal
ascendente, se deben buscar técnicas que permitan la utilización de todo el ancho de
banda para diferentes grupos de usuarios. Una primera técnica es la utilización de
múltiples fibra ópticas, cada una transportando las señales ascendentes de un grupo
reducido de usuarios por ejemplo, los usuarios de un mismo nodo. De esta manera, las
señales de retorno provenientes de los diferentes nodos que pertenecen a un mismo
centro nodal, no son combinadas dentro del centro nodal e inyectadas en una única fibra
óptica, sino que las mismas fibras ópticas son conducidas directamente para la
canalización hacia la cabecera. Se consigue así que le ancho de banda total de retorno
sea reutilizado por diferentes nodos, de manera que los usuarios que cuelgan de un
mismo nodo compartan los 50 MHz dedicados al canal de retorno. Esta alternativa, tal
como se ha analizado, comporta el uso de una fibra óptica (o dos en caso de la
redundancia) dedicada al canal ascendente para cada NOE, como se refleja en la
siguiente gráfica:

Gráfico 35: Conexión directa desde nodos hasta cabecera en el canal ascendente

Las opciones mencionadas comportan un número elevado de fibras ópticas. Se analizan

en los siguientes sub-apartados tres técnicas que permiten reducir el número de fibras
ópticas en el tramo centro nodal-cabecera, y entonces mantener la compartición del
ancho de banda del canal ascendente para un número reducido de usuarios: El uso de
bloques conversores de frecuencia, el uso de multiplexores ópticos y el posicionamiento
de servidores a niveles inferiores de la red. Las dos primeras técnicas se basan en la
transmisión de diferentes señales del canal de retorno por una única fibra óptica,
mientras que la tercera técnica consiste en procesar las señales de retorno antes, sin
transportarlos hasta la cabecera.

A.4.2 Técnicas de reutilización del canal de retorno:

Bloques convertidores: Una primera técnica que permite transmitir diferentes señales de
canales de retorno a través de una única fibra es la utilización de bloques convertidores
de frecuencia. Esta técnica, que trabaja a nivel eléctrico, consiste en coger diferentes
señales de un cierto ancho de banda y desplazar en frecuencia cada una de estas señales

250
para que cada una de ellas ocupe un margen de frecuencia diferente, con la finalidad de
poder combinarlos posteriormente sin solapamientos y pérdidas de información. Para
poder minimizar los problemas de distorsiones generadas en el proceso de combinación,
es necesario filtrar previamente las señales desplazadas en frecuencia y mantener los
márgenes de guarda entre ellos:

Gráfico 36: Filtrado previo de señales en el canal de retorno

El esquema global de esta solución se representa en el gráfico a continuación:

Gráfico 37: Esquema general del canal de retorno

En la cabecera será necesario deshacer el proceso hecho en el centro nodal. Se deberá

entonces convertir en eléctrica la señal óptica recibida, dividirla, filtrarla paso-banda
cada salida del divisor. Por último se debe desplazar en frecuencia cada señal obtenida
mediante Downconverters o bloques convertidores de bajada, para que vuelva a ocupar
el ancho de banda correspondiente al canal de retorno, de manera que pueda ser tratado
por los equipos de retorno de la cabecera.

Gráfico 38: Recepción de señales en la cabecera

Multiplexores ópticos: Una segunda técnica que permite transmitir diferentes señales de
canales de retorno a través de una única fibra es la utilización de multiplexación en
longitud de onda, WDM, y más concretamente, multiplexación densa en longitud de
onda, DWDM. El esquema global de esta solución se representa en el gráfico a
continuación:

251
 Gráfico 39: Utilización de multiplexores ópticos en el canal de retorno

Para centros nodales con un elevado número de nodos, pude emplearse una
combinación de las dos técnicas analizadas: Puede utilizarse la multiplexación en
longitud de onda para combinar las señales-bloque convertidas y multiplexadas
eléctricamente.

Posicionamiento de los servidores: El desplazamiento de los servidores acercándolos

hacia los usuarios, permite la evolución hacia diferentes grados de segmentación de la
red:
• Servidores en la cabecera: Situar los servidores en la cabecera conlleva la
necesidad de transportar las señales de Narrowcast y de canal de retorno desde la
cabecera hacia los usuarios y viceversa, recorriendo toda la red HFC. En la
cabecera se deberá entonces tener un gran espacio físico reservado a la
instalación de nuevos servidores. La ventaja de tener juntos todos los servidores
es que facilita la conexión tanto de con los sistemas de gestión, como con las
centrales y proveedores de servicios.
• Servidores en niveles inferiores: Situando los servidores en niveles inferiores de
la red, como por ejemplo en los centros nodales o en los NOE, se consigue que
las aplicaciones consuman recursos HFC sólo en el tramo centro nodal-usuario o
NOE-usuario. Además, se aumenta la segmentación de la red ya que cada
servidor se sitúa más cerca de los usuarios y da servicio a una zona geográfica
concreta. Esta alternativa comporta dos desventajas principales. Por un lado, el
hecho de situar los servidores en los centros nodales o en los NOE, ya que estos
requieren locales más grandes, más bien condicionados y conectados con la
cabecera para las funciones de gestión de los dispositivos.

Por un lado, se necesitará de red de trasporte adicional para conectar los dispositivos
HFC con las centrales o proveedores de servicio. Para el servicio de telefonía, los HDT
necesitan de red de transporte adicional (por ejemplo SDH) para transportar las señales
V5.2 hasta la central de conmutación. El uso de esta solución puede no ser conveniente
por razones de rendibilidad económica, si el operador de la red HFC no opera entonces
redes de transporte (SDH, IP, ATM) que lleguen a los centros nodales, de manera que
tengan que conectar el transporte a otras operadoras, o alquilar redes de transporte
externas.

A.5 GESTIÓN Y MANTENIMIENTO:

Cuando el operador desea crear una nueva red, se encuentra con tres puntos clave, el
diseño, la implementación y la posterior explotación. Estos tres puntos son claves ya
que cualquier error en alguno de ellos repercute en su buen funcionamiento, tanto de

252
cara a los clientes como de cara a los trabajadores propios del operador. E estos puntos
centraremos en la explotación de la red, es decir, el diseño ya se ha hecho y validado, y
ya se ha llevado a cabo su implementación física. Ahora es el momento de poner en
funcionamiento la red y controlar su buen comportamiento; entran en juego entonces las
funciones de gestión y mantenimiento:

A.5.1 Gestión:

Se entiende como gestión de un equipo la relación que se establece entre el operador y

el equipo en funcionamiento, que generalmente incluye funciones de configuración,
monitoreo y control. Si los equipos de la red son gestionables remotamente, el operador,
sin necesidad de desplazarse físicamente al lugar en donde se encuentra instalado un
equipo podrá:
• Realizar la configuración inicial del equipo una vez que el instalador comunique
que ya se ha realizado la conexión física.
• Modificar la configuración cuando surjan nuevos requerimientos.
• Interrogar la configuración actual y el estado de funcionamiento, mediante
técnicas de monitoreo remoto.
• Detectar anomalías o problemas de funcionamiento, mediante alarmas que el
equipo activa automáticamente y que se debe transportar al centro del operador,
en donde se recogen y analizan las alarmas recibidas, y se activan los procesos
necesarios para solucionar los problemas detectados.

Es importante que todos los elementos de la red sean gestionables remotamente y, es

interesante minimizar el número de sistemas de gestión dentro de una misma red. Se
debe tener en cuenta estas dos consideraciones a la hora de escoger los equipos de la
red, ya que facilitan bastante el trabajo del operador. El hecho de detectar al instante las
incidencias, y poder resolver un gran porcentaje de ellos remotamente, reduce el costo
de explotación de la red y reduce también los tiempos de resolución de problemas.
Consecuentemente, el cliente final ve incrementada la calidad y la disponibilidad de la
red, aumentando su grado de satisfacción respecto al servicio.

A.5.2 Mantenimiento:

El mantenimiento que un operador realiza sobre su red puede ser de tipo reactivo y/o de
tipo preventivo. E mantenimiento reactivo recoge todas aquellas acciones hechas
después de la aparición de una incidencia, mientras que el mantenimiento preventivo
actúa previamente a la aparición de incidencias. Es de suma importancia realizar un
buen mantenimiento preventivo (inspecciones periódicas de las instalaciones, medidas
de control, sustitución de equipos), ya que reduce considerablemente la aparición de
problemas y contribuye también en el aumento del grado de satisfacción de los clientes.

253